There was a podcast about async scala debugger in Eclipse:
http://skillsmatter.com/podcast/scala/iulian-dragos
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: http://akka.io/faq/
>> Search the archives: https://groups.google.com/group/akka-user
-
Hi Peter,
21 jan 2014 kl. 22:27 skrev Peter :
> Hi Roland
>
> I have a similar situation as Andrew but have been looking forward to 2.3 for
> the protobuf 2.5.0 dependency (vs protobuf 2.4.1 in akka 2.2.3). I've made
> use of your suggestion and copied Pipelines.scala & TcpPipelineHandler.scal
And I meant hack in the best sense, if you were wondering! So I should say
hAkk!
On Jan 21, 2014, at 7:09 AM, charlie robert wrote:
> Ok, they are on the list. I was looking at the network code… I don’t know
> what to say yet, as I don’t fully understand the flow of control of a
> functio
I never use step-through-debuggers :-)
On Jan 21, 2014 10:58 PM, "vijay krishna"
wrote:
> Oh ok is there a secret flag that you use internally to make it work
> synchronously ;-) just to validate the functionality.
>
> On Tuesday, January 21, 2014 11:31:06 AM UTC-8, √ wrote:
>>
>> Ok, I suspect t
Oh ok is there a secret flag that you use internally to make it work
synchronously ;-) just to validate the functionality.
On Tuesday, January 21, 2014 11:31:06 AM UTC-8, √ wrote:
>
> Ok, I suspect that a step-through-debugger won't be super-duper helpful
> since the code-path very likely is as
Hi Roland
I have a similar situation as Andrew but have been looking forward to 2.3
for the protobuf 2.5.0 dependency (vs protobuf 2.4.1 in akka 2.2.3). I've
made use of your suggestion and copied Pipelines.scala &
TcpPipelineHandler.scala appropriately to my project, it appears to be
working
Ok, I suspect that a step-through-debugger won't be super-duper helpful
since the code-path very likely is async :)
However, we have tests :)
On Tue, Jan 21, 2014 at 7:21 PM, vijay krishna wrote:
> Thanks Viktor I will got through the documentation :-). Actually thats
> promptly why I wanted t
On Tue, Jan 21, 2014 at 7:50 PM, Alistair George wrote:
> My plan for this was to have a proxy for NodeB watch state in NodeA. In
> normal (connected) operation it just remembers the current watch states
> (Actor Ax is/isn't watching Actor By) and passes the messages on to NodeB.
> If disconnect
My plan for this was to have a proxy for NodeB watch state in NodeA. In
normal (connected) operation it just remembers the current watch states
(Actor Ax is/isn't watching Actor By) and passes the messages on to NodeB.
If disconnected it just remembers the watch state. On reconnect, it sends a
Any update on this?
On Monday, 11 July 2011 06:52:40 UTC+1, Eugene Vigdorchik wrote:
>
> Hi Reuben,
> Deploying to EC2 instances is already implemented in Atmos, which is
> Akka commercial offering.
> The deployment is done by publishing to S3 first, and EC2 instances
> downloading from there.
> A
Thanks Viktor I will got through the documentation :-). Actually thats
promptly why I wanted to step thru a debugger to see what exactly happens
when tell() is called.
On Tuesday, January 21, 2014 8:49:56 AM UTC-8, √ wrote:
>
> Hi Vijay,
>
> Sometimes code is worth a thousand words:
>
>
> https
Hi all,
I'm constrained to Scala 2.9.2 and Akka 2.0.5 on my project and I am
confused how unhandled messages are intended to be logged.
It seems that in order to get any form of logging, the receive method must
use the LoggingReceive wrapper. This then shows handled and unhandled
messages in t
NodeA & NodeB are communicating
NodeB disappears (not acking)
NodeA still has things it needs to propagate to NodeB (watching actors on
that node etc), so they need to be buffered, also, if there are ordering
requirements it means that other things may not be transmitted/received
before other thing
I don't see where the unbounded buffer is needed. I'd be grateful for a bit
of explanation, especially since it looks like I'm going to have to
implement this stuff :)
On Tuesday, January 21, 2014 12:40:19 PM UTC, √ wrote:
>
> And it also introduces the need for unbounded buffering, i.e. memory
https://groups.google.com/forum/#!topic/akka-user/8fZ75MlVEYc
On Tuesday, January 21, 2014 8:15:38 PM UTC+4, Cédric Munger wrote:
>
> Hello,
>
> I've started to migrate from 2.3.M2 API to the RC1 and I have some very
> bad surprises on the IO API side.
> It looks like you've removed a LOT of thin
Hi Vijay,
Sometimes code is worth a thousand words:
https://github.com/akka/akka/blob/master/akka-actor/src/main/resources/reference.conf#L449
https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/serialization/Serializer.scala#L157
Cheers,
√
On Tue, Jan 21, 2014 at 5:14 PM,
Hey Viktor,
Just for the sake of clarity, If I send a byte[], Akka wont call any
serializer and just send the message as is, but if its an Object then it
would call the serializer class and serialize the message before sending it
right.
Best
Vj
On Monday, January 20, 2014 3:37:32 PM UTC-8, √ w
Hello,
I've started to migrate from 2.3.M2 API to the RC1 and I have some very bad
surprises on the IO API side.
It looks like you've removed a LOT of things here is a list of classes that
are missing between M2 and RC1 :
akka.io.AbstractSymmetricPipePair;
akka.io.PipePairFactory;
akka.io.Symme
Hi
I'm currently running performance tests using Gatling firing messages to
the Actor-Remote-Endpoint of my application.
The mailbox configuration of the endpoint is set to default (unbounded)
Sometimes it happens that my Gatling plugin is telling me that some
messages send to "Endpoint" ends
No, the point is to not create all actors with Akka.system().actorOf.
Inside an actor a child actor is created with getContext().actorOf.
/Patrik
On Tue, Jan 21, 2014 at 3:23 PM, Chanan Braunstein wrote:
> Hi Patrik,
>
> Is that just a matter of correct usage? In other words, If I made a top
> l
If you want more info about spray you can ask your question in the spray
mailing list: https://groups.google.com/group/spray-user/
On Tuesday, January 21, 2014 3:15:43 PM UTC+1, Robert Withers wrote:
>
> Hi pascal,
>
> This sounds promising. However, our kafka consumers need to do some DB
> cal
On Tue, Jan 21, 2014 at 3:40 PM, charlie robert wrote:
> For now we are using JDBC and the Oracle driver, so sync. Any discussion
> about async I would like to see.
>
>
As Ivan said, for JDBC, it's blocking by definition so if you don't want to
block your non-blocking actor system, you need to "
For now we are using JDBC and the Oracle driver, so sync. Any discussion about
async I would like to see.
These management and monitoring tools are key, so I would like to read about
them, as well. Typesafe Console on the list…what would be a few of the top
tools for Akka?
Just to give you a
Charlie,
doing DB calls in Spray has nothing special or different from what you
would do with plain Akka, Play or any other toolkit. Certainly, there is a
preference for using async and non-blocking drivers, but that is not a
requisite. What really matters in case you are doing blocking calls to a
I'm not an expert in Spray in prod (more Play experience) but there are a
few articles you can find on Google on how to monitor an Akka app...
You've got Typesafe Console naturally which is specifically dedicated to
this and a few tools to add on top of Akka!
Other people might have far better adv
Ok, they are on the list. I was looking at the network code… I don’t know
what to say yet, as I don’t fully understand the flow of control of a
functional programming language, but it looks tight. It’s a hack. There are a
lot of surrounding capability, but I see in Netty some listener logic
Oh, yes, could you also mention about management and monitoring with Spray, as
well?
- charlie
On Jan 21, 2014, at 7:15 AM, charlie robert wrote:
> Hi pascal,
>
> This sounds promising. However, our kafka consumers need to do some DB
> calls, but in a high volume sort of way. Could you say
On Tue, Jan 21, 2014 at 3:15 PM, charlie robert wrote:
> Hi pascal,
>
> This sounds promising. However, our kafka consumers need to do some DB
> calls, but in a high volume sort of way. Could you say a few words about
> database interactions in Spray?
>
>
Async DB Driver or Sync DB driver like
Hi pascal,
This sounds promising. However, our kafka consumers need to do some DB calls,
but in a high volume sort of way. Could you say a few words about database
interactions in Spray?
thanks,
charlie
On Jan 21, 2014, at 1:03 AM, Pascal Voitot Dev
wrote:
> Yes clearly you can get rid of
And it also introduces the need for unbounded buffering, i.e. memory leaks.
On Tue, Jan 21, 2014 at 1:01 PM, Akka Team wrote:
> Hi Alistair,
>
>
>
>
>>> I'm not sure this is desirable behaviour. I shouldn't have to restart a
>> process just to recover from a comms failure. After all, nothing in
Hi Piyush,
No, it is not possible in 2.2.x. If you have these problems you should
change the failure detectors to a less sensitive setting to reduce the
false positives.
In 2.3-RC1 this was changed, and now it is possible for a node to come back
from unreachable.
-Endre
On Tue, Jan 21, 2014 at
Hi Alistair,
>> I'm not sure this is desirable behaviour. I shouldn't have to restart a
> process just to recover from a comms failure. After all, nothing in the
> process has failed, and it may be providing services to other clients that
> have not suffered any comms failure. They shouldn't ha
We respectfully disagree then. Akka's design in this regard is highly
deliberate.
On Jan 21, 2014 12:35 PM, "Alistair George"
wrote:
>
>
> On Tuesday, January 21, 2014 8:44:17 AM UTC, Akka Team wrote:
>>
>> Hi Alistair,
>>
>>
>> On Tue, Jan 21, 2014 at 8:38 AM, Alistair George wrote:
>>
>>> Hi Ak
Hi All,
We are using akka cluster 2.2.3 in our project. During a highly memory
intensive operation cluster nodes start seeing each other as unreachable.
We perform a memory intensive operation across cluster which takes time as
well as garbage collection occurs on each node.
Is there any way
On Tuesday, January 21, 2014 8:44:17 AM UTC, Akka Team wrote:
>
> Hi Alistair,
>
>
> On Tue, Jan 21, 2014 at 8:38 AM, Alistair George
>
> > wrote:
>
>> Hi Akka,
>>
>> Thanks for the reply. One question: if (in 2.3) a remote actor system
>> becomes permanently quarantined, what do I have to do
But it is not a snapshot either in the sense of snapshot consistency
(because concurrency).
-Endre
On Tue, Jan 21, 2014 at 11:19 AM, √iktor Ҡlang wrote:
> It's always when it is applied, it's not a temporal query.
>
>
> On Tue, Jan 21, 2014 at 10:54 AM, Roger Alsing wrote:
>
>> What is actually
Oh well, we forgot to mention: Akka IO is no longer experimental. (and it
is part of the release)
We removed Pipelines though, but that does not affect the base actor based
API of IO.
We will fix the release notes.
-Endre
On Tue, Jan 21, 2014 at 11:15 AM, Andrew Gaydenko wrote:
> So 2.3.0 wi
It's always when it is applied, it's not a temporal query.
On Tue, Jan 21, 2014 at 10:54 AM, Roger Alsing wrote:
> What is actually matched when using a wildcard such as "*" ?
>
> Is it the actors that match the pattern _now_ , or is it the actors that
> match the pattern _over time_.
> that is,
So 2.3.0 will be released without IO at all. Have I missed something?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: http://akka.io/faq/
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you
What is actually matched when using a wildcard such as "*" ?
Is it the actors that match the pattern _now_ , or is it the actors that
match the pattern _over time_.
that is, is it a snapshot of actors at the time when the selection was
applied, or does it mean "a concurrent mutating child collec
"At some point you just have to move on..."
On Jan 21, 2014 9:44 AM, "Akka Team" wrote:
> Hi Alistair,
>
>
> On Tue, Jan 21, 2014 at 8:38 AM, Alistair George <
> alistairgeor...@gmail.com> wrote:
>
>> Hi Akka,
>>
>> Thanks for the reply. One question: if (in 2.3) a remote actor system
>> becomes
Hi!
On Tue, Jan 21, 2014 at 8:19 AM, wrote:
> I've been following AKKA for quite some time, but I'm confused what's the
> purpose of a cluster, in what aspect does it differ form the remote model.
>
> In the very beginning, I thought in one cluster there will only be one
> Akka system whose sin
Hi Chanan,
Nice to see that you were able to solve what you wanted.
I have one concern, please correct me if I have misunderstood the
implementation. This solution encourage creating lots of top level actors
without proper supervisor hierarchy. ActorScanner creates top level actors
for all Untype
Yes it is definitely possible, if you use akka-remote and akka-cluster then
it works seamlessly (in fact that is one of the main features of those --
to maintain location transparency of ActorRefs).
-Endre
On Tue, Jan 21, 2014 at 12:28 AM, Rob Withers wrote:
>
> > On Jan 20, 2014, at 3:57 PM,
Hi Stjepan,
You can dedicate a node to collect statistics and you can send counter
values from your routees to that collector node. Of course you need to be
aware that the collector node might crash and handle that situation.
-Endre
On Tue, Jan 21, 2014 at 12:39 AM, √iktor Ҡlang wrote:
> Hi St
Hi Alistair,
On Tue, Jan 21, 2014 at 8:38 AM, Alistair George
wrote:
> Hi Akka,
>
> Thanks for the reply. One question: if (in 2.3) a remote actor system
> becomes permanently quarantined, what do I have to do to re-establish
> communication once the comms problem is fixed?
>
First of all, quar
Yes clearly you can get rid of servlet stuff and go to frameworks like Play
or Spray!
Spray is more low-level and is better if you want pure REST (more is
possible too but it's more "manual" than Play). It's also 100% actor based
with akka.io
Play is full-stack and can help if you want more than ju
47 matches
Mail list logo
