These are chat archives for akkadotnet/akka.net

9th
Aug 2016
Aaron Stannard
@Aaronontheweb
Aug 09 2016 00:13
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
Joshua Hall
@joshuadeanhall
Aug 09 2016 00:22
@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."
Corneliu
@corneliutusnea
Aug 09 2016 00:39
@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
hidavidpeng
@hidavidpeng
Aug 09 2016 01:15
Hi All How to get the details of Akka config file?
Corneliu
@corneliutusnea
Aug 09 2016 01:22
@hidavidpeng you can provide config loader when you create your ActorSystem: ActorSystem.Create("Name", config) .. there are some samples around
Aaron Stannard
@Aaronontheweb
Aug 09 2016 01:25
@hidavidpeng check out the Config folders in each of the major modules
reference files are included in there
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 06:53
NeotericDev
@NeotericDev
Aug 09 2016 06:57
Hi All, Can someone help with the problem described in the above Stackoverflow link.
Aaron Stannard
@Aaronontheweb
Aug 09 2016 06:57
I just added two comments
looking at it
NeotericDev
@NeotericDev
Aug 09 2016 06:58
Will check that.
Aaron Stannard
@Aaronontheweb
Aug 09 2016 06:58
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
NeotericDev
@NeotericDev
Aug 09 2016 07:00
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.
Aaron Stannard
@Aaronontheweb
Aug 09 2016 07:02
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
NeotericDev
@NeotericDev
Aug 09 2016 07:05
IST(GMT +5.30)
Its okay, we can talk later
Aaron Stannard
@Aaronontheweb
Aug 09 2016 07:06
and this is just webcrawler out of the box, right?
nothing special in the configuration?
NeotericDev
@NeotericDev
Aug 09 2016 07:06
yes
no changes made
Aaron Stannard
@Aaronontheweb
Aug 09 2016 07:09
[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?
NeotericDev
@NeotericDev
Aug 09 2016 07:16
LightHouse is bound to the port 4053 running in another machine.
Aaron Stannard
@Aaronontheweb
Aug 09 2016 07:16
do you have logs for that? is it logging the connection attempts?
NeotericDev
@NeotericDev
Aug 09 2016 07:17
not logged yet, I will send you a detailed log file ASAP.
Aaron Stannard
@Aaronontheweb
Aug 09 2016 07:18
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
NeotericDev
@NeotericDev
Aug 09 2016 07:18
Sure..
Aaron Stannard
@Aaronontheweb
Aug 09 2016 07:18
sorry this stuff is causing you trouble - we'll get to the bottom of it
NeotericDev
@NeotericDev
Aug 09 2016 07:20
No problem, It could even be me doing something wrong somewhere. I will update you with the logs
Aaron Stannard
@Aaronontheweb
Aug 09 2016 07:20
thanks bud
NeotericDev
@NeotericDev
Aug 09 2016 07:21
take some rest bro.
Vagif Abilov
@object
Aug 09 2016 11:14
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?
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 11:17
@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
Vagif Abilov
@object
Aug 09 2016 11:18
@Horusiath hmm, quartz. Never heard of it, will have to check out.
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 11:18
Vagif Abilov
@object
Aug 09 2016 11:18
Thanks!
But there's nothing wrong with using perstistent actors for saga, is it? It's just a matter of right scheduling, correct?
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 11:19
yes
Vagif Abilov
@object
Aug 09 2016 11:19
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...
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 11:22
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
Vagif Abilov
@object
Aug 09 2016 11:24
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?
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 11:24
yes, it has pretty simple implementation if I remember correctly
Vagif Abilov
@object
Aug 09 2016 11:27
Looks like that, thanks again!
Vagif Abilov
@object
Aug 09 2016 15:04
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?
Vagif Abilov
@object
Aug 09 2016 15:31
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.
Vagif Abilov
@object
Aug 09 2016 16:50
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.
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 17:15
@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?
wdspider
@wdspider
Aug 09 2016 18:08
Is there an example project that uses the Cluster Sharding module? I'm having a bit of trouble envisioning how to use it.
Vagif Abilov
@object
Aug 09 2016 18:10
@Horusiath yes, I will try to extract a small example and check if it's still so slow. Then I will create an issue.
Aaron Stannard
@Aaronontheweb
Aug 09 2016 18:31
@wdspider yep, inside the main repo
Bartosz Sypytkowski
@Horusiath
Aug 09 2016 18:53
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?
Arsene T. Gandote
@Tochemey
Aug 09 2016 19:25
Hello please what is the best practice in using await inside a Receive of an Actor?
wdspider
@wdspider
Aug 09 2016 19:45
@Aaronontheweb found it, thanks :)
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:47
noice
qwoz
@qwoz
Aug 09 2016 19:48
@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?
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:48
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
qwoz
@qwoz
Aug 09 2016 19:49
Yeah, though the drawbacks of blocking the actor are still there, correct?
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:49
correct
they are
await has a cost associated with it
to11mtm
@to11mtm
Aug 09 2016 19:51
@Horusiath I have some great ideas for eventsourcing examples but you'd be doing my work lol.
Arsene T. Gandote
@Tochemey
Aug 09 2016 19:51
@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.
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:51
I don't recommend it
wdspider
@wdspider
Aug 09 2016 19:51
does the sharding stuff support multiple sets of actors? i.e. Actor A for Node Role A and Actor B for Node Role B ?
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:52
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
Arsene T. Gandote
@Tochemey
Aug 09 2016 19:54
ok
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:54
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
Arsene T. Gandote
@Tochemey
Aug 09 2016 19:55
@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?
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:55
no
use the async method
just don't await it
pipe the results to yourself instead
Arsene T. Gandote
@Tochemey
Aug 09 2016 19:55
Ok
I got it
explains that in more detail
although my comments about await in that blog post are outdated
as I mentioned earlier
qwoz
@qwoz
Aug 09 2016 19:57
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
Aaron Stannard
@Aaronontheweb
Aug 09 2016 19:59
you basically have to close over the bits of state you need
qwoz
@qwoz
Aug 09 2016 20:02
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.
Arsene T. Gandote
@Tochemey
Aug 09 2016 20:41
@Aaronontheweb How do we then use the ReceiveAsync seeing that Receive will be obsolete in the near versions?
qwoz
@qwoz
Aug 09 2016 21:28
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.
Arsene T. Gandote
@Tochemey
Aug 09 2016 22:21
I ask that question because of ContinueWith and PipeTo