Hey there,
We current run a spring-batch+spring-integration solution to do batch
processing in large scale through remote-chunking technique which makes
communication using request and replies queues. We're currently studying
akka and scala and we saw a few implementation ideas from
Hi,
Is there a way to change socket options such as send receive buffers from
the Java API?
All I can find is the set of Scala case classes (e.g.
http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize),
but to the best of my knowledge there is no way to use case
Hi Adam,
The Java API for that is here:
http://doc.akka.io/japi/akka/2.3.4/?_ga=1.146627261.86713299.1405931132
Cheers,
V
On Jul 23, 2014 10:24 AM, Adam adamho...@gmail.com wrote:
Hi,
Is there a way to change socket options such as send receive buffers
from the Java API?
All I can find is
Hi Adam,
Scala’s case classes are normal classes, they just come with a few
auto-generated methods (like productIterator() and static apply()). Nothing
stands in the way of using them just like any other Java class.
Regards,
Roland
23 jul 2014 kl. 10:24 skrev Adam adamho...@gmail.com:
Hi,
Hi Paul,
I think attaching an ID field is a very good practice anyway. In my
personal experience many patterns need a distinguishing field eventually,
there were several times in Akka internals even when we had to introduce
various IDs (ActorSystem instance IDs, ActorRef IDs, etc.). So I would
Hi Alexander,
On Tue, Jul 22, 2014 at 7:51 PM, Alexander Smirnov alsmirn...@gmail.com
wrote:
I run cluster of Actor nodes on AWS Autoscaling groups.
Before migration to version 2.3.4, cluster discovery worked just fine: new
instances join cluster, terminated machines switched to Unreachable
Hi Ryan,
On Tue, Jul 22, 2014 at 8:06 PM, Ryan Tanner ryan.tan...@gmail.com wrote:
This is an issue I've been dealing with for a while now. I was hoping
that the fix for log-remote-lifecycle-events = off in 2.2.4 would've fixed
it but it hasn't.
During multi-JVM cluster testing, we remove
Hi Diego,
This question is a bit too broadly scoped for us to answer (although the
community might help), these kind of questions are handled through our
professional services:
developer subscriptions (http://typesafe.com/how/subscription) or
consulting (http://typesafe.com/how/consulting).
Hi,
Thanks, this indeed works.
However, just for the record, the way to reference these classes is not
exactly as the average Java programmer would expect.
I had to decompile the Akka classes in order to understand what to do.
Because these are nested classes I initially expected the call to
23 jul 2014 kl. 12:39 skrev Adam adamho...@gmail.com:
Hi,
Thanks, this indeed works.
However, just for the record, the way to reference these classes is not
exactly as the average Java programmer would expect.
I had to decompile the Akka classes in order to understand what to do.
Wait...
As long as I'm looking at decompiled code, maybe this is just a
documentation issue.
Isn't this really the correct way to do this from Java code:
final Inet.SocketOption sendBufferSize = TcpSO.receiveBufferSize(1234);
It doesn't appear in the javadocs of 2.3.4, but the factory methods
Ah, right, that is the more direct route. This is in the JavaDoc by way of
“implemented super-interfaces”.
Regards,
Roland
23 jul 2014 kl. 12:49 skrev Adam adamho...@gmail.com:
Wait...
As long as I'm looking at decompiled code, maybe this is just a documentation
issue.
Isn't this really
OK.
Thanks a lot.
On Wednesday, July 23, 2014 1:52:57 PM UTC+3, rkuhn wrote:
Ah, right, that is the more direct route. This is in the JavaDoc by way of
“implemented super-interfaces”.
Regards,
Roland
23 jul 2014 kl. 12:49 skrev Adam adam...@gmail.com javascript::
Wait...
As long as
Thanks for the promptly response, Endre!
On Wednesday, July 23, 2014 6:51:27 AM UTC-3, Akka Team wrote:
Hi Diego,
This question is a bit too broadly scoped for us to answer (although the
community might help), these kind of questions are handled through our
professional services:
Many thanks for your help Endre.
Completely understood from shard perspective. I'll check if the entry
disappear if the actor is stopped (which is not the case for the sharding).
Regards.
El miércoles, 23 de julio de 2014 11:13:46 UTC+2, Akka Team escribió:
Hi Eduardo,
Shards are assumed
Hi,
I also tried scenario establish remote connection without sending any
application specific messages...without any success.
Finally I solved problem with protobuf dependency in our app and upgraded
to Akka 2.3.4
Everything works as expected (tried with 43 Tomcats).
On Tuesday, July 22,
First of all, thank you very much for the elaborate reply. I guess I'll get
hacking away at some prototypes soon and so some performance testing close
to our use-case. Looking forward to it, too :-)
One question remains:
Am Montag, 21. Juli 2014 13:28:27 UTC+2 schrieb Konrad Malawski:
The
Thanks so much! That EventFilter.mute was precisely what I needed.
We had so much log output from remoting that CircleCI was truncating our
logs so we weren't actually able to figure out which tests failed.
On Wednesday, July 23, 2014 3:48:02 AM UTC-6, Akka Team wrote:
Hi Ryan,
On Tue,
Ok. Entries are managed as expected. After looking at the code I understand
what you mean.
Thanks a lot for your help.
Regards.
El miércoles, 23 de julio de 2014 15:41:00 UTC+2, Eduardo Fernandes
escribió:
Many thanks for your help Endre.
Completely understood from shard perspective.
Hi guys:
Something that would be useful is a side effecting combinator. For
example, like doOnEach from RxJava. This would be particularly useful in
the actor world to insert an actor tell into the flow.
def doOnEach(f: = Unit): Flow[T]
For example:
flow.doOnEach { msg = if
20 matches
Mail list logo
