anyone had any luck running MSBuild on Windows Server 2016?
getting thousands of these
358) CS0012: Event\LoggingBus.cs(226,39): The type 'IEnumerable<>' is defined in an assembly that is not referenced. You
must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
I've installed some additional SDKs for .NET 4.6.1 (4.6.2 installer doesn't work on WS16 at the moment)
no dice
@Horusiath I finally got some logging setup and am seeing this. I assume that this error would prevent it from running.
2016-08-08 20:20:56.928 -04:00 [Error] "Failed to create snapshot directory C:\Program Files (x86)\IIS Express\snapshots"
[akka://MyServerX/system/akka.persistence.snapshot-store.local#264991178]: Akka.Actor.ActorInitializationException: Exception during creation ---> System.IO.IOException: Failed to create snapshot directory C:\Program Files (x86)\IIS Express\snapshots ---> System.UnauthorizedAccessException: Access to the path 'snapshots' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Directory.InternalCreateDirectory(String fullPath, String path, Object dirSecurityObj, Boolean checkHost)
at System.IO.DirectoryInfo.Create()
at Akka.Persistence.Snapshot.LocalSnapshotStore.GetSnapshotDir()
--- End of inner exception stack trace ---
at Akka.Persistence.Snapshot.LocalSnapshotStore.GetSnapshotDir()
at Akka.Persistence.Snapshot.LocalSnapshotStore.PreStart()
at Akka.Actor.ActorBase.AroundPreStart()
at Akka.Actor.ActorCell.<>c__DisplayClass154_0.<Create>b__0()
at Akka.Actor.ActorCell.UseThreadContext(Action action)
at Akka.Actor.ActorCell.Create(Exception failure)
--- End of inner exception stack trace ---
at Akka.Actor.ActorCell.Create(Exception failure)
at Akka.Actor.ActorCell.SysMsgInvokeAll(EarliestFirstSystemMessageList messages, Int32 currentState)
2016-08-08 20:20:56.933 -04:00 [Information] "Message LoadSnapshot from akka://MyServerX/user/employeeActor to akka://MyServerX/system/akka.persistence.snapshot-store.local was not delivered. 2 dead letters encountered."
@joshuadeanhall I haven't used the persistence but looking at the code I think it's trying to save a snapshop in the program files folder
where the IISExpress is running from
most probably you can configure a folder where the snapshot will be stored
akka.persistence.snapshot-store.local.dir = folder
Hi All How to get the details of Akka config file?
@hidavidpeng you can provide config loader when you create your ActorSystem:
ActorSystem.Create("Name", config) .. there are some samples around
@hidavidpeng check out the
Config folders in each of the major modules
reference files are included in there
@Aaronontheweb I belive you could help with that: http://stackoverflow.com/questions/38821779/what-are-the-changes-in-akka-net-cluster-1-0-8-and-1-1-1
Hi All, Can someone help with the problem described in the above Stackoverflow link.
I just added two comments
looking at it
Will check that.
the fact that it's a connection TIMEOUT issue
indicates environmental problems - means the machine is reachable but non-responsive
also, please make sure all nodes are running the same version of the software
1.1 was a major change - we tested that you can upgrade a live cluster from 1.0.8 to 1.1
and that works
but we can't account for every possible configuration
I am sure all nodes are having same version 1.1.1.
If, suppose it is an environmental problems Software running on v1.0.8 should also not work , if am right.
that depends
we changed the socket implementation in 2.1.1 to use a later generation of async APIs, so if you're running on older servers that could be an issue
although it'd have to be really fucking old
but the fact that scores of other users are running 1.1.1 fine in production with no issue
and it's running substantially better than 1.0.8
would indicate it's an issue with your specific configuration
why it worked on 1.0.8 and why it's not on 1.1.1 is something I don't have enough information to answer given what's posted there
what timezone are you in? I could do a skype call tomorrow and dig into it
it's midnight here and I've been up since about 4:45 this morning so I'm just about out of gas :p
IST(GMT +5.30)
Its okay, we can talk later
and this is just webcrawler out of the box, right?
nothing special in the configuration?
yes
no changes made
[07:07:22][Step 3/3] docker: Executing the command using /bin/bash (38s)
[07:07:22][docker] Executing command: docker run --rm=true --name=teamcity_cJC4gJmxMVrEKzhPBOfHTZ7anrN90WXk -v /home/AkkaDotNet/BuildAgent/work/d395f960b2ec7618:/home/AkkaDotNet/BuildAgent/work:rw --workdir=/home/AkkaDotNet/BuildAgent/work/ --interactive=false --tty=false akkadotnet/mono-base:latest /bin/bash -c "source teamcity7923634774190982146.build.cmd"
[07:07:22][docker] Starting: /home/AkkaDotNet/BuildAgent/temp/agentTmp/custom_script7339520437593709260
[07:07:22][docker] in directory: /home/AkkaDotNet/BuildAgent/work/d395f960b2ec7618
[07:07:23][docker] --2016-08-09 07:07:23-- https://www.nuget.org/nuget.exe
[07:07:24][docker] Resolving www.nuget.org (www.nuget.org)... 191.236.146.247
[07:07:24][docker] Connecting to www.nuget.org (www.nuget.org)|191.236.146.247|:443... connected.
[07:07:24][docker] HTTP request sent, awaiting response... 302 Found
[07:07:24][docker] Location: https://api.nuget.org/downloads/nuget.exe [following]
[07:07:24][docker] --2016-08-09 07:07:24-- https://api.nuget.org/downloads/nuget.exe
[07:07:25][docker] Resolving api.nuget.org (api.nuget.org)... 93.184.215.200, 2606:2800:11f:179a:1972:2405:35b:459
[07:07:25][docker] Connecting to api.nuget.org (api.nuget.org)|93.184.215.200|:443... connected.
[07:07:25][docker] HTTP request sent, awaiting response... 200 OK
[07:07:25][docker] Length: 1686528 (1.6M) [application/octet-stream]
[07:07:25][docker] Saving to: `/home/AkkaDotNet/BuildAgent/work/.nuget/nuget.exe'
[07:07:25][docker]
[07:07:25][docker] 0K .......... .......... .......... .......... .......... 3% 3.92M 0s
[07:07:25][docker] 50K .......... .......... .......... .......... .......... 6% 6.05M 0s
[07:07:25][docker] 100K .......... .......... .......... .......... .......... 9% 22.8M 0s
[07:07:25][docker] 150K .......... .......... .......... .......... .......... 12% 5.88M 0s
[07:07:25][docker] 200K .......... .......... .......... .......... .......... 15% 27.5M 0s
[07:07:25][docker] 250K .......... .......... .......... .......... .......... 18% 6.70M 0s
[07:07:25][docker] 300K .......... .......... .......... .......... .......... 21% 28.1M 0s
[07:07:25][docker] 350K .......... .......... .......... .......... .......... 24% 21.9M 0s
[07:07:25][docker] 400K .......... .......... .......... .......... .......... 27% 9.82M 0s
[07:07:25][docker] 450K .......... .......... .......... .......... .......... 30% 31.3M 0s
[07:07:25][docker] 500K .......... .......... .......... .......... .......... 33% 25.3M 0s
[07:07:25][docker] 550K .......... .......... .......... .......... .......... 36% 24.8M 0s
[07:07:25][docker] 600K .......... .......... .......... .......... .......... 39% 23.3M 0s
[07:07:25][docker] 650K .......... .......... .......... .......... .......... 42% 9.01M 0s
[07:07:25][docker] 700K .......... .......... .......... .......... .......... 45% 16.8M 0s
[07:07:25][docker] 750K .......... .......... .......... .......... .......... 48% 16.4M 0s
[07:07:25][docker] 800K .......... .......... .......... .......... .......... 51% 18.8M 0s
[07:07:25][docker] 850K .......... .......... .......... .......... .......... 54% 25.2M 0s
[07:07:25][docker] 900K .......... .......... .......... .......... .......... 57% 23.3M 0s
[07:07:25][docker] 950K .......... .......... .......... .......... .......... 60% 13.3M 0s
[07:07:25][docker] 1000K .......... .......... .......... .......... .......... 63% 20.4M 0s
[07:07:25][docker] 1050K .......... .......... .......... .......... .......... 66% 15.6M 0s
[07:07:25][docker] 1100K .......... .......... .......... .......... .......... 69% 14.4M 0s
[07:07:25][docker] 1150K .......... .......... .......... .......... .......... 72% 19.4M 0s
[07:07:25][docker] 1200K .......... .......... .......... .......... .......... 75% 22.4M 0s
[07:07:25][docker] 1250K .......... .......... .......... .......... .......... 78% 23.3M 0s
[07:07:25][doc
yesssssssssssssssssssssssssssss
got the build server to start using Docker images to run Mono builds
was able to update the Docker image remotely and see the change affected on the build server without having to update the VM
finally. Took all damn day lol
@NeotericDev for your cluster issue, can you post a log dump to a text file rather than a screenshot for a couple of your nodes?
specifically I want to see the confirmation messages showing that each node bound to its address correctly
the fact that you're getting a timeout is weird
which node is bound to 4053 in this example?
LightHouse is bound to the port 4053 running in another machine.
do you have logs for that? is it logging the connection attempts?
not logged yet, I will send you a detailed log file ASAP.
cool, update the SO issue with a link to that in a github gist or a pastebin
I'll check it out in the AM
Sure..
sorry this stuff is causing you trouble - we'll get to the bottom of it
No problem, It could even be me doing something wrong somewhere. I will update you with the logs
thanks bud
take some rest bro.
A small question: does it feel right implementing sagas that may take days by scheduling persistent actors? I.e. a persistent actor is scheduled to be awaken at some time by a certain message. Does this scheduled message survive system restart?
@object no, it won't. Scheduling works great for small intervals of time (subseconds to minutes, maybe hours)
for long periods, you could use quartz for akka
@Horusiath hmm, quartz. Never heard of it, will have to check out.
Thanks!
But there's nothing wrong with using perstistent actors for saga, is it? It's just a matter of right scheduling, correct?
yes
Thanks.
But isn't it overkill using another lib for relatively easy task? Because scheduling can also be implemented by introducing another persistent actor that would contain scheduling details.
Or maybe it will quickly become complex enough...
yes, it could - I was proposing to use persistent actors for long-range scheduling in the past, but no one has need/time to implement that
I see. I am looking at Quartz, you said "Quartz for Akka", I've found https://github.com/akkadotnet/Akka.Quartz.Actor, this one you meant?
yes, it has pretty simple implementation if I remember correctly
Looks like that, thanks again!
Looks like I am not correctly configuring SqlServer plugin for persistence queries. I am getting "Unable to create read journal plugin instance type Akka.Persistence.SqlServer.Journal.SqlServerJournal".
I am executing the following statement: PersistenceQuery.Get(system).ReadJournalFor<SqlReadJournal>("akka.persistence.journal.sql-server")
The SqlServer Akka plugin works fine for persistent actors and configured with plugin id "sql-server".
Isn't this sufficient for use in persistent queries?
OK, I managed to get rid of an exception by using plugin id "akka.persistence.query.journal.sql", but is this right? I am actually using an SQL Server plugin.
Eventually managed to get persistent queries with SQL Server plugin (yes, I had to use "akka.persistence.query.journal.sql" as plugin id). First experience is strange: it takes almost forever to execute AllPersistentIds for the first time - and I only have 300+ records in EventJournal. I have old custom code that does this quickly without using persistent queries, I was about to replace it with standard implementation but first I have to figure out why it is grotesquely slow. It returns within a few seconds only if I limit the number of results with Take(small_number), otherwise it takes minutes.
@object the reason for SQL read journal config is that there is only one, used by all SQL plugins (which are compatible with akka.persistence.query at least) - so you don't need to specify versions directed to different SQL databases
also for the case of AllPersistentIds - could you setup an issue?
Is there an example project that uses the Cluster Sharding module? I'm having a bit of trouble envisioning how to use it.
@Horusiath yes, I will try to extract a small example and check if it's still so slow. Then I will create an issue.
@wdspider yep, inside the main repo
btw. guys, I want to finish my CQRS/Eventsourcing akka sample - but it looks like I'm a very unimaginative person. I need some kind of simple event stormed scenario to program, something that could be used for learning purposes. Do you know anything about such scenarios?
Hello please what is the best practice in using await inside a Receive of an Actor?
@Aaronontheweb found it, thanks :)
noice
@Tochemey Lots of discussions here as well as blog posts. Perhaps start with the top two results here https://duckduckgo.com/?q=site%3Apetabridge.com+await&ia=web and then ask for clarification on anything you still don't understand?
my blog post on PipeTo vs. async / await is a bit out of date
wrote that before Akka.NET 1.0 :p
we support async / await inside Akka.NET actors now
didn't at the time
I would still use PipeTo, personally
Yeah, though the drawbacks of blocking the actor are still there, correct?
correct
they are
await has a cost associated with it
@Horusiath I have some great ideas for eventsourcing examples but you'd be doing my work lol.
@qwoz I am just asking best practices. So far I have been using await inside my Receive. I just want to know whether it is recommended.
I don't recommend it
does the sharding stuff support multiple sets of actors? i.e. Actor A for Node Role A and Actor B for Node Role B ?
avoid it if possible and use PipeTo instead
PipeTo doesn't block the actor
so you can kick off an asynchronous task and pipe it back to the actor as a message later
the actor can keep doing other things while that task is running
the only case where I think using await makes a lot of sense inside an actor is if you have complex error handling routines
where you might be doing multiple chained async operations
and have to handle exceptions for each
ok
that's easier to express with await
doing that with
ContinueWith and PipeTo can be cumbersome
if your error handling is pretty simple
i.e. pass / fail error handling
then you're better off with a continuation and pipe to
@Aaronontheweb So if I am using a third party lib that offers async methods and sync method I should rather use the sync method. Am I right?
no
use the async method
just don't await it
pipe the results to yourself instead
Ok
I got it
explains that in more detail
although my comments about await in that blog post are outdated
as I mentioned earlier
It'd be really nice if the ContinueWith/PipeTo had a bit more syntactic sugar around it... it's a bit cumbersome to take the result and, if the next thing depends on state from the current message, having to wrap the state in order to be able to process it for the next thing.
I'm not sure if that's feasible or even possible
you basically have to close over the bits of state you need
Yeah... it just seems like there must be a better way. For example, if you want to lookup who owns an object, then do something if that owner has
IsAdmin = true setting. Currently you might lookup by ID to fetch the user record and, based on that, find the pref, then perform the original action. This might vary depending on if you're looking up the owner vs. the creator, for instance. So there's a bunch of what feels like unnecessary keyboard mashing in order to pass along enough information to be able to process the result based on the state of the original request.
@Aaronontheweb How do we then use the ReceiveAsync seeing that Receive will be obsolete in the near versions?
Receive<Foo>(async foo => ... is obsolete; you need to use ReceiveAsync<Foo>(async foo => ... instead. As far as I know, Receive<Foo>(foo => ... isn't going away.
I ask that question because of ContinueWith and PipeTo