[akka-user] Aeron as Akka's transport layer ?

[Soumya Simanta]

Aeron looks like a very promising transport layer for Akka given that its 
message based and Layer 4 protocol (same as TCP) 

https://groups.google.com/forum/#!msg/mechanical-sympathy/fr7moLcsuiI/XsKndzoR6ycJ

Would like to know the thought of others ? 



Thanks
-Soumya

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Using akka-stream to build async pipeline

[Leon Ma]

Nice! I will take a look.

在 2014年11月17日星期一UTC-8上午5时22分47秒，Konrad Malawski写道：
>
> Hi Leon,
> akka-streams is *exactly* an "async pipeline for data processing" :-)
> As it's currently "pre experimental" we do not yet provide comprehensive 
> docs - this should change in a matter of weeks though.
> If you want to get hakking on it ASAP, the best documentation is API 
> comments and our tests in: 
> https://github.com/akka/akka/tree/release-2.3-dev/akka-stream-tests/src/test/scala/akka/stream/scaladsl
>  
> 
>
> Happy hakking and please look forward to our 1.0 release which is coming 
> "soon" (then, with docs!).
>
> On Mon, Nov 17, 2014 at 10:10 AM, Leon Ma 
> > wrote:
>
>> Hi, 
>>
>> I'm wondering if akka-stream is a good candidate for creating an async 
>> pipeline for data processing.
>>
>> Take http request as example, I'd like the request go thru a series of 
>> pipeline handlers 1 by 1 asynchronously and finally get a response.
>>
>> More over, I'd like to see it's capable to jump from 1 handler to another 
>> conditionally.
>>
>> If it's applicable , any document or sample code I can start with?
>>
>>
>> Thanks
>>
>> Leon
>>
>>
>>
>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
>
> 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Camel & ActiveMQ oneway

[Raymond Roestenburg]

Hi Jeroen,

Your approach is correct, and it is intended to override routeResponse if
you need different behavior, see the docs.

 /**
   * Called after a response was received from the endpoint specified by
endpointUri. The
   * response is passed as argument. By default, this method sends the
response back to the original sender
   * if oneway is false. If oneway
is true, nothing is
   * done. This method may be overridden by subtraits or subclasses (e.g.
to forward responses to another
   * actor).
   */

It is assumed that when you set oneway to true that you really are not
interested in the result. In your specific case you do need it. See
http://krasserm.blogspot.com.au/2011/02/akka-producer-actor-new-features-and.html
for some history on this feature, it was called receiveAfterProduce at the
time.

On Sat, Nov 8, 2014 at 8:39 AM, Jeroen Gordijn 
wrote:

> Hi all,
>
> I want to place a message on a JMS Queue with Akka-Camel. This works just
> fine, however I want to be sure that the message was really placed on the
> queue. The queue is oneway, so I do not expect any response from another
> consumer. However, when I configure this in my code as oneway, the actor
> sending to the producer does not get any notification that the message was
> really delivered on the queue.
>
> ProducerSupport in Akka-Camel has the following code:
>   protected def routeResponse(msg: Any): Unit = if (!oneway) sender()
> ! transformResponse(msg)
>
> This means that I do not get any response when oneway is configured. But
> the endpoint does give feedback whether the message was delivered and this
> is now lost. I solved it by putting the following code in my own producer:
>
>   override protected def routeResponse(msg: Any): Unit = sender() !
> transformResponse(msg)
>
> Is there any reason for the if statement? Can anything go wrong when the
> if statement is dropped in the akka-camel codebase?
>
> Thanks,
> Jeroen
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Raymond Roestenburg

code: http://github.com/RayRoestenburg
blog: http://roestenburg.agilesquad.com
twtr: @RayRoestenburg
book: http://manning.com/roestenburg

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] ActorPath vs ActorSelection in AtLeastOnceDelivery

[Ryan Bair]

I'm wondering why AtLeastOnceDelivery's deliver method uses ActorPath 
instead of ActorSelection. Under the hood, it creates an ActorSelection 
from the ActorPath, but I'm unclear as to why it doesn't accept 
ActorSelection as deliver's parameter.

In another post inquiring about the use of ActorPath[1], it was explained 
that ActorPath was used instead of ActorRef because actor/jvm crashes will 
result in the ActorRefs no longer being valid. However, isn't this behavior 
of ActorRefs also the reason that ActorSelection was created? If so, would 
using ActorSelection be more clear/consistent?

[1] 
https://groups.google.com/forum/#!searchin/akka-user/actorselection$20deliver/akka-user/i0yHKffw9jU/ImTAZkAM7tkJ

Thanks

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka persistentChannel does not delete message from Journal upon confirm

['Michael Overmeyer' via Akka User List]

Nevermind. I was mistaken. While the upgrade to akka 2.3.5 made the leak 
less obvious, it still exists. I have submitted a pull request to the 
example code Manas provided in order to make it more obvious.

On Tuesday, 26 August 2014 10:36:27 UTC-4, Michael Overmeyer wrote:
>
> For what it's worth, I checked out the code that Manas provided (
> https://github.com/manasdebashiskar/akkapersistenceExample) and changed 
> the build.scala to use Scala 2.10.4.
> That itself changed nothing, and the problem still existed.
>
> However, when I changed the build.scala to use Akka 2.3.5 (ignoring the 
> deprecation warnings since Persistent Channels, etc, are now deprecated), 
> this problem seems to have gone away.
>
> On Wednesday, 26 March 2014 10:06:23 UTC-4, Martin Krasser wrote:
>>
>>  
>> On 26.03.14 14:20, Manas Kar wrote:
>>  
>> Thanks Martin for helping me with this. I will keep an eye on this 
>> ticket. 
>> I realized that I never thanked you for the awesome piece of work you 
>> have done on Akka persistence to make our life so easy. 
>>  
>>
>> Thanks you!
>>
>>  
>>  ...Manas
>>
>> On Wednesday, March 26, 2014 3:46:29 AM UTC-4, Martin Krasser wrote: 
>>>
>>>  Hi Manas,
>>>
>>> I can reproduce what you reported and need to investigate that further. 
>>> I verified that the written messages are actually deleted and that there 
>>> are no additional writes of messages or confirmation markers made by your 
>>> app. I'm quite busy with other stuff at the moment, so it may take a while. 
>>> Ticket created: https://www.assembla.com/spaces/akka/tickets/3962
>>>
>>> Thanks for testing and reporting
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 25.03.14 19:25, Manas Kar wrote:
>>>  
>>> Hi Martin,  
>>>  To answer your previous question nothing happens if I restart my 
>>> application. The persisted files don't get deleted. I also tested the code 
>>> with a smaller size message and was able to see the same problem.
>>>  I have created a very simple runnable application that uses 
>>> PersistenceChannel to send messages to a IOWorker that immediately confirms 
>>> the message. As stated above; this examples shows how the journal space 
>>> keeps growing over time even though the message gets  confirmed and 
>>> should be deleted after a while asynchronously.
>>>
>>>  The code is placed here 
>>> . 
>>>
>>> Once again thanks for your help. I am sure it is something that I am 
>>> doing wrong because of which only I see this and no-one else seems to be 
>>> complaining about. 
>>>
>>>  ...Manas
>>>
>>>  
>>> On Friday, March 21, 2014 3:49:17 AM UTC-4, Martin Krasser wrote: 

  
 On 19.03.14 15:38, Manas Kar wrote:
  
 Hi Martin, 
  I have a process that is running since last Sunday evening using the 
 above code base(Given here 
 )
  
 . The journal space has grown to be around 24 GB so far. I am still 
 continuing my run to see when the compaction will happen and the "marked 
 deleted" messages will be physically deleted. 


 What happens when you restart the application?

  The only way my code is different than your example is that my 
 message has the size of 8 MB. Could that be playing some role? 
  

 No.

  
 Thanks 
 Manas


 On Wednesday, March 12, 2014 1:09:38 PM UTC-4, Manas Kar wrote: 
>
> Thanks Martin. 
>  That explains what I am seeing.
>
> On Wednesday, March 12, 2014 12:15:15 PM UTC-4, Martin Krasser wrote: 
>>
>>  
>> On 11.03.14 19:22, Manas Kar wrote:
>>  
>> Hi Martin,  
>>  I observed something that kind of contradicts my previous statement. 
>> It would be correct to say that the size of journal folder is 
>> approximately 
>> half the size of SumOf(messages).
>>
>>   My messages don't get replayed after the configurable times from 
>> the channels. But the journal's are not physically deleted amounting to 
>> large disk usage.
>>  Please find my modified scala code that follows the example you 
>> provided and still leaves residues in journal folder. 
>>  
>>
>> LevelDB doesn't delete entries immediately, it rather marks them as 
>> deleted and physically deletes them during compactions. Details at 
>> http://leveldb.googlecode.com/svn/trunk/doc/impl.html.
>>
>>  
>>  Thanks
>> ...Manas
>>
>>
>> On Tuesday, March 11, 2014 2:19:51 AM UTC-4, Manas Kar wrote: 
>>>
>>> Hi,  
>>>  I am very excited about the latest and the biggest feature of 
>>> Akka2.3.0 that is Persistence. 
>>>  I have posted a question about Akka persistentChannel here. 
>>> 

[akka-user] Reactive actor-actor communication

[Adam Warski]

Hello,

I was looking at AtLeastOnceDelivery and what problems it might have when 
the destination actor dies or becomes slow. Apart from the obvious 
out-of-memory which would eventually happen (and which can be solved with a 
smarter ALOD version which flushes excess data to disk), there's also the 
problem of an increasing load of messages when the destination is 
unavailable: every new message is retried, and retried, and retried, and 
this adds up ... wouldn't it be a perfect place for a reactive message 
stream?

Are "reactive message streams" between actors anything that has been 
considered? (I know that for sure it's not implemented, but just wondering 
in general, if it makes sense.) This could be especially useful if the 
actors are on separate nodes - "reactive remoting".

One problem here would be handling routers. Let's say we have an A actor 
streaming messages to two B actors:

  /-- B1
A --- R --- <
  \-- B2

where R is a router. Now the router would have be smart about the demand 
coming from B1 and B2: sum the demand and return it to A, and when A sends 
messages, split them according to the earlier requests.

Going even further (and that is the original problem that I was wondering 
about), let's say we have a pool of A-actors (potentially on different 
cluster nodes using e.g cluster sharding) and a pool of B-actors (again 
potentially on different cluster nodes). The goal is to have a reliable 
message stream between the A-actors and the B-actors. The additional 
complication here is that there's no central router, so even if there was a 
reactive message stream available between any two nodes, the B-actors would 
have no idea how to split the demand between the A-actors. Or maybe the 
direction I'm heading with this is somehow wrong? :)

Adam

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to filter out unwanted message based on IP Address

[Michael Frank]

what is the mechanism by which the message is being received?  is this a 
message sent via akka remoting, or is this a TCP connection being 
accepted by akka IO, or a spray HTTP request, or ?


if it is a message that was sent via remoting, you can look at the 
Address of the sender() actor ref.  sender().path.address will contain 
the address of the sender.  see 
http://doc.akka.io/api/akka/2.3.7/index.html#akka.actor.Address


if it is a TCP connection accepted by akka IO, then the Connected 
message will contain the remote and local InetSocketAddress.  see 
http://doc.akka.io/docs/akka/2.3.7/scala/io-tcp.html#Accepting_connections


-Michael

On 11/14/14 00:27, JasonQ wrote:

Hello,

I'm wondering whether AKKA has some mechanism which can be used to 
filter out incoming message based on IP Address, e.g. if I don't want 
to process messages from some specific node, how should I do?


Thanks.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
http://doc.akka.io/docs/akka/current/additional/faq.html

>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google 
Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to akka-user+unsubscr...@googlegroups.com 
.
To post to this group, send email to akka-user@googlegroups.com 
.

Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


--

 Read the docs: http://akka.io/docs/
 Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Persistence on the Query Side: The Conclusion

[Vaughn Vernon]

Hi Roland,

I am still tracking this one. As far as I know the team hasn't gotten back 
to this work yet. How are Akka Streams looking in support of this effort? 
Anything I can do to help move this forward?

Best,
Vaughn


On Monday, October 6, 2014 11:32:20 PM UTC-6, rkuhn wrote:
>
> Hi Vaughn,
>
> from our side nothing has happened yet: my conclusion is that this thread 
> contains all the information we need when we start working on this. The 
> reason why we are waiting is that this work will depend heavily upon Akka 
> Streams and therefore we are finishing those first, which should take 
> roughly one month. Meanwhile, if use cases come up which could be used to 
> refine the plans, please point them out here so that we can take all the 
> inputs into account.
>
> Regards,
>
> Roland
>
> 6 okt 2014 kl. 20:09 skrev Vaughn Vernon  >:
>
> Hi Roland,
>
> I's been a month this the last update on this and I have lost track of the 
> status.
>
> Can you provide an update on where this stands? Is there a more recent 
> akka-persistence build that supports the conclusions reached in this 
> discussion? If so, what is the release number? If no, when is will the 
> proposed features be released?
>
> Best,
> Vaughn
>
> On Fri, Sep 5, 2014 at 1:09 AM, Roland Kuhn  > wrote:
>
>> Attempting a second round-up of what shall go into tickets, in addition 
>> to my first summary we need to:
>>
>>
>>- predefine trait JournalQuery with minimal semantics (to make the 
>>Journal support discoverable at runtime)
>>- predefine queries for named streams since that is universally 
>>useful; these are separate from PersistenceID queries due to different 
>>consistency requirements
>>- add support for write-side tags (see below)
>>- add a comprehensive PersistenceTestKit which supports the 
>>fabrication of arbitrary event streams for both PersistentActor and 
>>read-side verification
>>
>>
>> Ashley, your challenge about considering non-ES write-sides is one that I 
>> think we might not take up: the scope of Akka Persistence is to support 
>> persistent Actors and their interactions, therefore I believe we should be 
>> opinionated about how we achieve that. If you want to use CQRS without ES 
>> then Akka might just not be for you (for some values of “you”, not 
>> necessarily you ;-) ).
>>
>> Now why tags? My previous conclusion was that burdening the write-side 
>> with generating them goes counter to the spirit of ES in that this tagging 
>> should well be possible after the fact. The problem is that that can be 
>> extremely costly, so spawning a particular query on the read-side should 
>> not implicitly replay all events of all time, that has the potential of 
>> bringing down the whole system due to overload. I still think that stores 
>> might want to offer this feature under the covers—i.e. not accessible via 
>> Akka Persistence standard APIs—but for those that cannot we need to provide 
>> something else. The most prominent use of tags will probably be that each 
>> kind of PersistentActor has its own tag, solving the type issue as well (as 
>> brought up by Alex and Olger). In summary, write-side tags are just an 
>> optimization.
>>
>> Concerning the ability to publish to arbitrary topics from any Actor I am 
>> on the fence: this is a powerful feature that can be quite a burden to 
>> implement. What we are defining here is—again—Akka Persistence, meaning 
>> that all things that are journaled are intended to stay there eternally. 
>> Using this to realize a (usually ephemeral) event bus is probably going to 
>> suffer from impedance mismatches, as witnessed by previous questions 
>> concerning the efficiency of deleting log entries—something that should 
>> really not be done in the intended use-cases. So, if an Actor wants to 
>> persist an Event to make it part of the journaled event stream, then I’d 
>> argue that that Actor is at least conceptually a PersistentActor. What is 
>> wrong with requiring it to be one also in practice? The only thing that we 
>> might want to add is that recovery (i.e. the write-side reading of events) 
>> can be opted out of. Thoughts?
>>
>> For everything going beyond the above I’d say we should wait and see what 
>> extensions are provided by Journal implementations and how well they work 
>> in practice.
>>
>> Regards,
>>
>> Roland
>>
>> 27 aug 2014 kl. 16:34 skrev Roland Kuhn 
>> >:
>>
>> Dear hakkers,
>>
>> there have been several very interesting, educational and productive 
>> threads in the past weeks (e.g. here 
>>  and 
>> here ). 
>> We have taken some time to distill the essential problems as well as 
>> discuss the proposed solutions and below is my attempt at a summary. In the 
>> very likely case that I missed something, by all means please raise your 
>> voice. The intention for this thread is 

Re: [akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[Konrad Malawski]

Thanks for the description Maxim, would you mind opening an issue on our
issue tracker  using the data you've
collected so far (the stacktrace and your descrition here)?
Sounds like there may be something on our side we should look deeper into.

Thanks in advance!

On Mon, Nov 17, 2014 at 3:25 PM, Maxim Valyanskiy 
wrote:

> Hello!
>
> Our application provides REST interface to database storage. User uploads
> data via HTTP interface, we store it to JDBC and then do some additional
> logic that processes uploaded data. HTTP interface is implemented via Spray
> 1.3.2; Akka version 2.3.6 (but I have seen this problem in previous 2.3.x).
> We do not use akka-streams.
>
> We create and then stop an some number of actors per upload; also we use
> transformation operations on Future in context dispatcher.
>
> We see this exception when client continuously uploads large number of
> objects (about a million). I do not know the way to reproduce this bug
> (other that posting a lot of data and waiting before the problem occurs).
>
> Maxim
>
> понедельник, 17 ноября 2014 г., 17:04:30 UTC+3 пользователь Konrad
> Malawski написал:
>
>> Hi Maxim,
>> We fixed a very similar bug in akka-streams 0.11, but it does not seem
>> that’s the exact place that your stacktrace is coming from…
>> Here’s the issue we fixed in 0.11 => https://github.com/akka/
>> akka/issues/16263
>>
>> Would you mind giving more background on what you’ve been using and when
>> this appeared?
>> Are you using akka streams?
>> Which version of akka etc are you using?
>>
>> Thanks for the additional info, let’s try looking into it.
>>
>> --
>> Konrad 'ktoso' Malawski
>> hAkker @ typesafe
>> http://akka.io
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] [akka-streams] ActorPublisher-based Source

[Boris Lopukhov]

Hi everyone!

I am trying to create a stream with an ActorPublisher:

class SourceActor extends ActorPublisher[List[Int]] {
  import akka.stream.actor.ActorPublisherMessage.Request

  var list = List.range(1, 21).grouped(5).toList // for example

  def receive = {
case Request(elems) => while (totalDemand > 0 && isActive) {
  list match {
case Nil =>
  onComplete()
  self ! PoisonPill
case head :: tail =>
  list = tail
  onNext(head)
  }
}
  }
}

val sourceActor = system.actorOf(Props[SourceActor])
val source = Source(ActorPublisher[List[Int]](sourceActor))
val out = ForeachSink(println)
source.mapConcat{x => x}.runWith(out)

I expect to see numbers from 1 to 20, but random printed from 1 to 17~19
As I understand, it occur due to the stream complete before all elements 
are processed. How can I implement an ActorPublisher properly and escape 
this problem?

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Router Like Behavior with Streams

[Danny Browning]

The main use case would be a flexiroute or groupBy with an elastic cluster.
Since remoting/clustering is down the road, was just looking for a possible
way to use streams with remoting/clustering, other than
ActorPublisher/ActorSubscriber.

On Mon, Nov 17, 2014 at 5:05 AM, Konrad Malawski  wrote:

> Hi Danny,
> What you describe sounds more like an "stream of streams" scenario (like
> our groupBy
> 
>  for
> example) - using it you can create substreams based on some key and then
> produce to that substream.
> In FlexiRoute / FlexiMerge it's not supported to change the number of
> endpoints - it's a static junction currently.
>
> If you could come up on a few use case descriptions and maybe formulate
> them as an issue  we can take a look
> at it during our planing and decide if it's something fundamental enough to
> include as building block or if it's something that should be described as a
> cookbook recipe as "how to build these kinds of junctions if you need
> one". We definitely do appreciate your feedback, thanks a lot in advance!
>
>
>
> On Thu, Nov 13, 2014 at 4:04 PM,  wrote:
>
>> Are there plans to add routers to streams? FlexiRoute accomplishes some
>> of that behavior, but I'm not seeing how to safely dynamically add/remove
>> OutputHandles. Also not sure of how one would accomplish consistent
>> hashing, where we're looking to split up a stream to specific processors
>> for the purpose of state maintenance. Wasn't sure how to create a state
>> where you wait till an element is ready, then wait for demand for the
>> output that the element hashes to. Alternatively, buffer elements/outputs
>> until an element hashes to an output with demand.
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/HyvIUMaIBbQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[Maxim Valyanskiy]

Hello!

Our application provides REST interface to database storage. User uploads 
data via HTTP interface, we store it to JDBC and then do some additional 
logic that processes uploaded data. HTTP interface is implemented via Spray 
1.3.2; Akka version 2.3.6 (but I have seen this problem in previous 2.3.x). 
We do not use akka-streams.

We create and then stop an some number of actors per upload; also we use 
transformation operations on Future in context dispatcher.

We see this exception when client continuously uploads large number of 
objects (about a million). I do not know the way to reproduce this bug 
(other that posting a lot of data and waiting before the problem occurs).

Maxim

понедельник, 17 ноября 2014 г., 17:04:30 UTC+3 пользователь Konrad Malawski 
написал:
>
> Hi Maxim,
> We fixed a very similar bug in akka-streams 0.11, but it does not seem 
> that’s the exact place that your stacktrace is coming from…
> Here’s the issue we fixed in 0.11 => 
> https://github.com/akka/akka/issues/16263
>
> Would you mind giving more background on what you’ve been using and when 
> this appeared?
> Are you using akka streams?
> Which version of akka etc are you using?
>
> Thanks for the additional info, let’s try looking into it.
>
> -- 
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
> http://akka.io
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[√iktor Ҡlang]

Also, could you have your logger output the full stack trace?

On Mon, Nov 17, 2014 at 3:02 PM, Konrad 'ktoso' Malawski <
konrad.malaw...@typesafe.com> wrote:

> Hi Maxim,
> We fixed a very similar bug in akka-streams 0.11, but it does not seem
> that’s the exact place that your stacktrace is coming from…
> Here’s the issue we fixed in 0.11 =>
> https://github.com/akka/akka/issues/16263
>
> Would you mind giving more background on what you’ve been using and when
> this appeared?
> Are you using akka streams?
> Which version of akka etc are you using?
>
> Thanks for the additional info, let’s try looking into it.
>
> --
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
> http://akka.io
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[Konrad 'ktoso' Malawski]

Hi Maxim,
We fixed a very similar bug in akka-streams 0.11, but it does not seem that’s 
the exact place that your stacktrace is coming from…
Here’s the issue we fixed in 0.11 => https://github.com/akka/akka/issues/16263

Would you mind giving more background on what you’ve been using and when this 
appeared?
Are you using akka streams?
Which version of akka etc are you using?

Thanks for the additional info, let’s try looking into it.

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[Maxim Valyanskiy]

Hello!

I'm running Akka application that sometimes logs ISE in 
BatchingExecutor$Batch.run. I can't find any application class in it stack 
trace, all classes in it are Akka internal. Is it a problem (bug) in 
application or in Akka? How to find the cause of it?

Here it the complete stack trace:

[incident-daemon-system-akka.actor.default-dispatcher-233] ERROR 
akka.dispatch.Dispatcher - exception in sameThreadExecutionContext 
(a.d.Dispatcher)
java.lang.IllegalStateException: exception in sameThreadExecutionContext
at 
akka.dispatch.ExecutionContexts$sameThreadExecutionContext$.reportFailure(Future.scala:76)
 

at 
scala.concurrent.impl.CallbackRunnable.executeWithValue(Promise.scala:40) 
at 
scala.concurrent.impl.Promise$DefaultPromise.tryComplete(Promise.scala:248) 
at scala.concurrent.Promise$class.complete(Promise.scala:55) 
at 
scala.concurrent.impl.Promise$DefaultPromise.complete(Promise.scala:153) 
at scala.concurrent.Future$$anonfun$map$1.apply(Future.scala:235) 
at scala.concurrent.Future$$anonfun$map$1.apply(Future.scala:235) 
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32) 
at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.processBatch$1(BatchingExecutor.scala:67)
 

at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply$mcV$sp(BatchingExecutor.scala:82)
 

at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply(BatchingExecutor.scala:59)
 

at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply(BatchingExecutor.scala:59)
 

at 
scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:72) 
at 
akka.dispatch.BatchingExecutor$Batch.run(BatchingExecutor.scala:58) 
at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:41) 
at 
akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393)
 

at 
scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) 
at 
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
 

at 
scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) 
at 
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
 

Caused by: java.lang.IllegalArgumentException: requirement failed
at scala.Predef$.require(Predef.scala:207) 
at 
akka.dispatch.BatchingExecutor$Batch.run(BatchingExecutor.scala:55) 
at 
akka.dispatch.ExecutionContexts$sameThreadExecutionContext$.unbatchedExecute(Future.scala:74)
 

at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.processBatch$1(BatchingExecutor.scala:76)
 

at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply$mcV$sp(BatchingExecutor.scala:82)
 

at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply(BatchingExecutor.scala:59)
 

at 
akka.dispatch.BatchingExecutor$Batch$$anonfun$run$1.apply(BatchingExecutor.scala:59)
 

at 
scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:72) 
at 
akka.dispatch.BatchingExecutor$Batch.run(BatchingExecutor.scala:58) 
at 
akka.dispatch.ExecutionContexts$sameThreadExecutionContext$.unbatchedExecute(Future.scala:74)
 

at 
akka.dispatch.BatchingExecutor$class.execute(BatchingExecutor.scala:110) 
at 
akka.dispatch.ExecutionContexts$sameThreadExecutionContext$.execute(Future.scala:73)
 

... 19 common frames omitted

Maxim

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Using akka-stream to build async pipeline

[Konrad Malawski]

Hi Leon,
akka-streams is *exactly* an "async pipeline for data processing" :-)
As it's currently "pre experimental" we do not yet provide comprehensive
docs - this should change in a matter of weeks though.
If you want to get hakking on it ASAP, the best documentation is API
comments and our tests in:
https://github.com/akka/akka/tree/release-2.3-dev/akka-stream-tests/src/test/scala/akka/stream/scaladsl

Happy hakking and please look forward to our 1.0 release which is coming
"soon" (then, with docs!).

On Mon, Nov 17, 2014 at 10:10 AM, Leon Ma  wrote:

> Hi,
>
> I'm wondering if akka-stream is a good candidate for creating an async
> pipeline for data processing.
>
> Take http request as example, I'd like the request go thru a series of
> pipeline handlers 1 by 1 asynchronously and finally get a response.
>
> More over, I'd like to see it's capable to jump from 1 handler to another
> conditionally.
>
> If it's applicable , any document or sample code I can start with?
>
>
> Thanks
>
> Leon
>
>
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Accessing Future's onComplete Internal variables

[Konrad 'ktoso' Malawski]

You’ll have to block then.
Consider using Actors instead if you can.

— k 

On 17 November 2014 at 13:51:29, Syd Gillani (s.zeeshangill...@gmail.com) wrote:

Alright, but I would like to send the result to an API ( a method in an 
external class). Is there any way for it. Cheers


Syd


On Monday, 17 November 2014 12:35:42 UTC+1, Konrad Malawski wrote:
Have you looked into our pipeTo pattern? It allows to send the result of a 
Future to an Actor, without having to block on the result:


import static akka.pattern.Patterns.pipe;

 
final ActorRef alice = ???;
final Future future = ???;

pipe(future, ec).to(alice);

Alice can receive the value and do things with it.
More info in the docs: 
http://doc.akka.io/docs/akka/2.3.7/java/untyped-actors.html#Ask__Send-And-Receive-Future

-- k 

On Mon, Nov 17, 2014 at 12:22 PM, Syd Gillani  wrote:
Thanks Konrad,
The issue with the mapping is that I won't be able to send the results to an 
external class -- that is exactly my case. I need to send the result of the 
future to an external class which will perform some other computation and so. 
I knew about the await method, but as It is described in the documentation (not 
a preferred approach  ), so I was hesitant to use it. Cheers

Syd




On Monday, 17 November 2014 12:10:16 UTC+1, Konrad Malawski wrote:
Hi Syd,
your code samples are not valid Java (well, the first one could be if testVar 
would be a field, but that's unsafe instead maybe use `AtomicReference` and 
`set` it from the completion?).
OnComplete has a `void` method so you cannot return from it.

Instead of taking things out of the future like this you can either:
1) keep mapping (transfroming the value):


future.map(new Function1(){
  @Override public Object apply(Object v1) {
return null;
  }
}, ec);
never getting out of this transformation - this way you can chain all 
transformations you need.

2) Await on the result of the future (we discourage this) as it will block the 
thread that you're calling await from:


Future future = null;
Object o = scala.concurrent.Await.result(future, Duration.apply(100, 
TimeUnit.DAYS))

Hope this helps, happy hakkionmg!

On Mon, Nov 17, 2014 at 11:36 AM, Syd Gillani  wrote:
Hi,

I wanted to ask if there is any way to map the internal variables to the 
external java ones. For instance, for the following method

String testVar=null;


future.onComplete(new OnComplete(){
        public void onComplete(Throwable t, Object result){
     
         testVar=(String) result;
      
        }
    }, ec);


I have tried the following method to get the results by calling onSuccess

future.onComplete(new OnComplete(){
        public void onComplete(Throwable t, Object result){
     
       return result;
      
        }
    }, ec);


future.onSuccess(new Result(), ec);


However I am kept on getting the error (cannot cast the Result class to a 
partial function ).  Cheers



--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe


--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.



--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe


--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

-- 
>>  Read the d

Re: [akka-user] Accessing Future's onComplete Internal variables

[Syd Gillani]

Alright, but I would like to send the result to an API ( a method in an 
external class). Is there any way for it. Cheers


Syd


On Monday, 17 November 2014 12:35:42 UTC+1, Konrad Malawski wrote:
>
> Have you looked into our pipeTo pattern? It allows to send the result of a 
> Future to an Actor, without having to block on the result:
>
> import static akka.pattern.Patterns.pipe;
>
> 
> final ActorRef alice = ???;
> final Future future = ???;
> pipe(future, ec).to(alice);
>
>
> Alice can receive the value and do things with it.
> More info in the docs: 
> http://doc.akka.io/docs/akka/2.3.7/java/untyped-actors.html#Ask__Send-And-Receive-Future
>
> -- k 
>
> On Mon, Nov 17, 2014 at 12:22 PM, Syd Gillani  > wrote:
>
>> Thanks Konrad,
>> The issue with the mapping is that I won't be able to send the results to 
>> an external class -- that is exactly my case. I need to send the result of 
>> the future to an external class which will perform some other computation 
>> and so. 
>> I knew about the await method, but as It is described in the 
>> documentation (not a preferred approach  ), so I was hesitant to use it. 
>> Cheers
>>
>> Syd
>>
>>
>>
>>
>> On Monday, 17 November 2014 12:10:16 UTC+1, Konrad Malawski wrote:
>>>
>>> Hi Syd,
>>> your code samples are not valid Java (well, the first one could be if 
>>> testVar would be a field, but that's unsafe instead maybe use 
>>> `AtomicReference` and `set` it from the completion?).
>>> OnComplete has a `void` method so you cannot return from it.
>>>
>>> Instead of taking things out of the future like this you can either:
>>> 1) keep mapping (transfroming the value):
>>>
>>> future.map(new Function1(){
>>>   @Override public Object apply(Object v1) {
>>> return null;
>>>   }
>>> }, ec);
>>>
>>> never getting out of this transformation - this way you can chain all 
>>> transformations you need.
>>>
>>> 2) Await on the result of the future (*we discourage this*) as it will 
>>> block the thread that you're calling await from:
>>>
>>> Future future = null;
>>> Object o = scala.concurrent.Await.result(future, Duration.apply(100, 
>>> TimeUnit.DAYS))
>>>
>>>
>>> Hope this helps, happy hakkionmg!
>>>
>>> On Mon, Nov 17, 2014 at 11:36 AM, Syd Gillani  
>>> wrote:
>>>
 Hi,

 I wanted to ask if there is any way to map the internal variables to 
 the external java ones. For instance, for the following method

 String testVar=null;


 future.onComplete(new OnComplete(){
 public void onComplete(Throwable t, Object result){
  
  testVar=(String) result;
   
 }
 }, ec);


 I have tried the following method to get the results by calling 
 onSuccess

 future.onComplete(new OnComplete(){
 public void onComplete(Throwable t, Object result){
  
return result;
   
 }
 }, ec);


 future.onSuccess(new Result(), ec);


 However I am kept on getting the error (cannot cast the Result class to 
 a partial function ).  Cheers



  -- 
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ: http://doc.akka.io/docs/akka/
 current/additional/faq.html
 >> Search the archives: https://groups.google.com/
 group/akka-user
 --- 
 You received this message because you are subscribed to the Google 
 Groups "Akka User List" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to akka-user+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Cheers,
>>> Konrad 'ktoso' Malawski
>>> hAkker @ Typesafe
>>>
>>>
>>>   -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
>
>  

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscri

Re: [akka-user] Re: Akka, Camel and RabbitMQ - Asynchronously acknowledging specific message

[Konrad Malawski]

Hi guys,
to put some team perspective on it - basically the feature did not pull
it's weight so it was discontinued.
Also, for things like these external integrations, we feel it's better left
up to the community as they really use these external libraries
and care a lot about them on a daily basis, if we on the other hand take up
such kind of integration, we much match release cycles and
keep the module up to date in normal akka releases etc. So it is a lot of
weight which needs to give equally as much value, in this case we thought
it's better to leave out.

As Todd already mentioned, there is this one library, and recently the guys
from scalac have developed an akka-streams integration to rabbit:
https://github.com/ScalaConsultants/reactive-rabbit
So while akka-streams are still "pre-experimental" you could have a look
into it as it looks pretty interesting, though it's your call if you want
to go prod with these (streams are not yet supported by us, but will be
soon).

Happy hakking!


On Sun, Nov 16, 2014 at 9:25 AM, Tal Pressman  wrote:

> Thanks, I'll have a look at it.
> I would have preferred something maintained by Typesafe or some other
> "dependable" organization, but I guess beggars can't be choosers.
>
>
> On Monday, November 10, 2014 4:19:33 PM UTC+2, Todd Nist wrote:
>>
>> @Tal,
>>
>> You may be able to use https://github.com/sstone/amqp-client in place of
>> akka-amqp.
>>
>> -Todd
>>
>>
>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka persistence: Optimistic Locking

[Konrad Malawski]

Hi Martin,
This is all journal dependent - it's up to the journal implementation to
decide how to deal with this,
where as the default answer should be that "don't do this". Otherwise you'd
have to lock and/or coordinate before every write to make sure you're the
one writing - this costs a lot.

Summing up:
* don't assume journals will magically fix this,
* use cluster sharding or cluster singleton to make sure you have one
persistent actor for a given key performing the writes,
* if you do write from multiple sources to one persistence id - expect
things will break in recovery - yes.

On Fri, Nov 14, 2014 at 9:11 PM, Olger Warnier  wrote:

> Hi Martin,
>
> In my experience, the last update for a specific sequence number is kept.
> With a replay, you'll end up with a mixed state.
>
> Kind regards,
>
> Olger
>
> On Friday, November 14, 2014 1:16:27 PM UTC+1, Martin Jöhren wrote:
>>
>> Hi,
>>
>> what would happen when two different servers somehow create a persistent
>> actor with the same persistence id and then storing some events? I think
>> the sequence number will go out of sync and of course the state of the
>> aggregate is also out of sync but what happens then from a runtime
>> perspective? Does the system continue running and will fail only next time
>> I recover?
>>
>> Any details about that appreciated.
>>
>> Best
>>
>> Martin
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Remoting, NAT, and Containers

[Akka Team]

On Sat, Nov 15, 2014 at 9:51 PM, Ryan Tanner  wrote:

> This is what we're doing in production.  I'm working on a writeup which I
> will hopefully have up in a few weeks (I know I've said that before ;))


That would be a nice read, looking forward to it, Ryan!


-- 
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Router Like Behavior with Streams

[Konrad Malawski]

Hi Danny,
What you describe sounds more like an "stream of streams" scenario (like
our groupBy

for
example) - using it you can create substreams based on some key and then
produce to that substream.
In FlexiRoute / FlexiMerge it's not supported to change the number of
endpoints - it's a static junction currently.

If you could come up on a few use case descriptions and maybe formulate
them as an issue  we can take a look
at it during our planing and decide if it's something fundamental enough to
include as building block or if it's something that should be described as a
cookbook recipe as "how to build these kinds of junctions if you need one".
We definitely do appreciate your feedback, thanks a lot in advance!



On Thu, Nov 13, 2014 at 4:04 PM,  wrote:

> Are there plans to add routers to streams? FlexiRoute accomplishes some of
> that behavior, but I'm not seeing how to safely dynamically add/remove
> OutputHandles. Also not sure of how one would accomplish consistent
> hashing, where we're looking to split up a stream to specific processors
> for the purpose of state maintenance. Wasn't sure how to create a state
> where you wait till an element is ready, then wait for demand for the
> output that the element hashes to. Alternatively, buffer elements/outputs
> until an element hashes to an output with demand.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Accessing Future's onComplete Internal variables

[Konrad Malawski]

Have you looked into our pipeTo pattern? It allows to send the result of a
Future to an Actor, without having to block on the result:

import static akka.pattern.Patterns.pipe;


final ActorRef alice = ???;
final Future future = ???;
pipe(future, ec).to(alice);


Alice can receive the value and do things with it.
More info in the docs:
http://doc.akka.io/docs/akka/2.3.7/java/untyped-actors.html#Ask__Send-And-Receive-Future

-- k

On Mon, Nov 17, 2014 at 12:22 PM, Syd Gillani 
wrote:

> Thanks Konrad,
> The issue with the mapping is that I won't be able to send the results to
> an external class -- that is exactly my case. I need to send the result of
> the future to an external class which will perform some other computation
> and so.
> I knew about the await method, but as It is described in the documentation
> (not a preferred approach  ), so I was hesitant to use it. Cheers
>
> Syd
>
>
>
>
> On Monday, 17 November 2014 12:10:16 UTC+1, Konrad Malawski wrote:
>>
>> Hi Syd,
>> your code samples are not valid Java (well, the first one could be if
>> testVar would be a field, but that's unsafe instead maybe use
>> `AtomicReference` and `set` it from the completion?).
>> OnComplete has a `void` method so you cannot return from it.
>>
>> Instead of taking things out of the future like this you can either:
>> 1) keep mapping (transfroming the value):
>>
>> future.map(new Function1(){
>>   @Override public Object apply(Object v1) {
>> return null;
>>   }
>> }, ec);
>>
>> never getting out of this transformation - this way you can chain all
>> transformations you need.
>>
>> 2) Await on the result of the future (*we discourage this*) as it will
>> block the thread that you're calling await from:
>>
>> Future future = null;
>> Object o = scala.concurrent.Await.result(future, Duration.apply(100, 
>> TimeUnit.DAYS))
>>
>>
>> Hope this helps, happy hakkionmg!
>>
>> On Mon, Nov 17, 2014 at 11:36 AM, Syd Gillani 
>> wrote:
>>
>>> Hi,
>>>
>>> I wanted to ask if there is any way to map the internal variables to the
>>> external java ones. For instance, for the following method
>>>
>>> String testVar=null;
>>>
>>>
>>> future.onComplete(new OnComplete(){
>>> public void onComplete(Throwable t, Object result){
>>>
>>>  testVar=(String) result;
>>>
>>> }
>>> }, ec);
>>>
>>>
>>> I have tried the following method to get the results by calling onSuccess
>>>
>>> future.onComplete(new OnComplete(){
>>> public void onComplete(Throwable t, Object result){
>>>
>>>return result;
>>>
>>> }
>>> }, ec);
>>>
>>>
>>> future.onSuccess(new Result(), ec);
>>>
>>>
>>> However I am kept on getting the error (cannot cast the Result class to
>>> a partial function ).  Cheers
>>>
>>>
>>>
>>>  --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>>> current/additional/faq.html
>>> >> Search the archives: https://groups.google.com/
>>> group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> Konrad 'ktoso' Malawski
>> hAkker @ Typesafe
>>
>>
>>   --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Accessing Future's onComplete Internal variables

[Syd Gillani]

Thanks Konrad,
The issue with the mapping is that I won't be able to send the results to 
an external class -- that is exactly my case. I need to send the result of 
the future to an external class which will perform some other computation 
and so. 
I knew about the await method, but as It is described in the documentation 
(not a preferred approach  ), so I was hesitant to use it. Cheers

Syd




On Monday, 17 November 2014 12:10:16 UTC+1, Konrad Malawski wrote:
>
> Hi Syd,
> your code samples are not valid Java (well, the first one could be if 
> testVar would be a field, but that's unsafe instead maybe use 
> `AtomicReference` and `set` it from the completion?).
> OnComplete has a `void` method so you cannot return from it.
>
> Instead of taking things out of the future like this you can either:
> 1) keep mapping (transfroming the value):
>
> future.map(new Function1(){
>   @Override public Object apply(Object v1) {
> return null;
>   }
> }, ec);
>
> never getting out of this transformation - this way you can chain all 
> transformations you need.
>
> 2) Await on the result of the future (*we discourage this*) as it will 
> block the thread that you're calling await from:
>
> Future future = null;
> Object o = scala.concurrent.Await.result(future, Duration.apply(100, 
> TimeUnit.DAYS))
>
>
> Hope this helps, happy hakkionmg!
>
> On Mon, Nov 17, 2014 at 11:36 AM, Syd Gillani  > wrote:
>
>> Hi,
>>
>> I wanted to ask if there is any way to map the internal variables to the 
>> external java ones. For instance, for the following method
>>
>> String testVar=null;
>>
>>
>> future.onComplete(new OnComplete(){
>> public void onComplete(Throwable t, Object result){
>>  
>>  testVar=(String) result;
>>   
>> }
>> }, ec);
>>
>>
>> I have tried the following method to get the results by calling onSuccess
>>
>> future.onComplete(new OnComplete(){
>> public void onComplete(Throwable t, Object result){
>>  
>>return result;
>>   
>> }
>> }, ec);
>>
>>
>> future.onSuccess(new Result(), ec);
>>
>>
>> However I am kept on getting the error (cannot cast the Result class to a 
>> partial function ).  Cheers
>>
>>
>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
>
>  

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Accessing Future's onComplete Internal variables

[Konrad Malawski]

Hi Syd,
your code samples are not valid Java (well, the first one could be if
testVar would be a field, but that's unsafe instead maybe use
`AtomicReference` and `set` it from the completion?).
OnComplete has a `void` method so you cannot return from it.

Instead of taking things out of the future like this you can either:
1) keep mapping (transfroming the value):

future.map(new Function1(){
  @Override public Object apply(Object v1) {
return null;
  }
}, ec);

never getting out of this transformation - this way you can chain all
transformations you need.

2) Await on the result of the future (*we discourage this*) as it will
block the thread that you're calling await from:

Future future = null;
Object o = scala.concurrent.Await.result(future, Duration.apply(100,
TimeUnit.DAYS))


Hope this helps, happy hakkionmg!

On Mon, Nov 17, 2014 at 11:36 AM, Syd Gillani 
wrote:

> Hi,
>
> I wanted to ask if there is any way to map the internal variables to the
> external java ones. For instance, for the following method
>
> String testVar=null;
>
>
> future.onComplete(new OnComplete(){
> public void onComplete(Throwable t, Object result){
>
>  testVar=(String) result;
>
> }
> }, ec);
>
>
> I have tried the following method to get the results by calling onSuccess
>
> future.onComplete(new OnComplete(){
> public void onComplete(Throwable t, Object result){
>
>return result;
>
> }
> }, ec);
>
>
> future.onSuccess(new Result(), ec);
>
>
> However I am kept on getting the error (cannot cast the Result class to a
> partial function ).  Cheers
>
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Accessing Future's onComplete Internal variables

[Syd Gillani]

Hi,

I wanted to ask if there is any way to map the internal variables to the 
external java ones. For instance, for the following method

String testVar=null;


future.onComplete(new OnComplete(){
public void onComplete(Throwable t, Object result){
 
 testVar=(String) result;
  
}
}, ec);


I have tried the following method to get the results by calling onSuccess

future.onComplete(new OnComplete(){
public void onComplete(Throwable t, Object result){
 
   return result;
  
}
}, ec);


future.onSuccess(new Result(), ec);


However I am kept on getting the error (cannot cast the Result class to a 
partial function ).  Cheers



-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Cluster sharding : changing the persistence store

[Jean Helou]

Hi, 

Some context 

We are working on a public accessible web application (openoox.com). At the 
moment the application run on play 2.3.6 and akka 2.3.6

We have implemented sharding in our application to distribute the load of 
some user actions throughout our cluster. At the moment cluster sharding is 
the only thing we use which depends on akka persistence. 
Our application uses mongodb as its main datastore, and when implementing 
the sharding prototype we 
used https://github.com/ironfish/akka-persistence-mongo to get a shared 
journal.

Using mongodb as a journal store doesn't seem to be the best option but we 
don't really have the time to setup an alternate store at the moment. We 
will probably do so as we start moving business actors to an akka 
persistence implementation. 

One last point to note is we use a rolling deployment configuration where 
"new" and "old" servers live and communicate together for about 30 minutes 
before the old servers are taken down.Which means that akka nodes with the 
new and old configuration live in the same cluster for a while. 

The questions 
 
- Is there anything to help us migrate the existing Cluster sharding 
 events to the new store ? It isn't clear to us how we will be able to do 
the migration ... our understanding of the documentation is that an actor 
system can only have one backing store for akka persistence. 
This means a migration plan would probably require creating another actor 
system with the new backing store, implementing a custom persistent actor 
in both actor systems using the same persistence id as our shard 
coordinators and forward the recovered events from the actor backed by the 
old store to the actor backed with the new store. I think we should also 
delay shard startup until the migration is over, would that be enough not 
to loose events ?
 
- In the event we are unable to migrate the events, what would the 
consequences be for the sharded cluster ? More specifically would the nodes 
backed by the new store sill be able to process their shards or should we 
plan downtime for the website while we do the migration ?

Does anyone have experience with these kind of problems ? Should we avoid 
migration entirely and delay the deployment of sharding until we have time 
to setup a more appropriate store for akka persistence ?

We would welcome insight before we take time to experiment ... 

Thanks
Jean

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Using akka-stream to build async pipeline

[Leon Ma]

Hi, 

I'm wondering if akka-stream is a good candidate for creating an async 
pipeline for data processing.

Take http request as example, I'd like the request go thru a series of 
pipeline handlers 1 by 1 asynchronously and finally get a response.

More over, I'd like to see it's capable to jump from 1 handler to another 
conditionally.

If it's applicable , any document or sample code I can start with?


Thanks

Leon




-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: How to Monitor akka, improving performance

[Gaurav Sharma]

Hi,
I'm doing nothing in the third actor. Once received the message is simple 
discarded. I'm simply doing a tell on the actor and passing the message 
through it.

One of the major reasons I posted this thread was to help my self 
understand the Visual VM. I'm not clear what the various dispatcher with 
numbers that appear in my snapshot signify. What are these entries? Why are 
the there? 
My code is using  single ActorSystem.



On Sunday, November 16, 2014 7:27:05 AM UTC+5:30, Soumya Simanta wrote:
>
> How are you "saving" the record in actor3 ? 
> How are you passing the messages between the actors ? I mean do you have 
> any code waits in the receive of any of the actors? 
> Can you see how frequently is your GC invoked and how it changes with the 
> size of the message? 
>
>
>
> On Thursday, November 13, 2014 12:59:07 AM UTC-5, Gaurav Sharma wrote:
>>
>> Hi,
>> I have a single node system where I'm having three actors. This node is 
>> running on a single port. I'm simply passing data and my message flow is:
>>
>> actor1 -> actor2 -> actor3
>>
>> Now actor actor3 is created within actor 1. Its a flow where I send a 
>> record from actor1 to actor2 and then it comes to actor3 where the record 
>> is clubbed and saved. In my current code, I'm not doing anything specific 
>> and only passing a string of size 5987 bytes 25k times a second.
>>
>> But, what happens is that my system hangs after a while and the same runs 
>> fine when the string is very small like "demo". I'm inspecting the system 
>> using Jvisual VM and I noticed a very strange thing today. Most of my 
>> threads where in wait situation, the socket.accept took most of the time.
>>
>> So, I need some help in understanding the image below - 
>>
>>
>> 
>>
>> 1. What is the ClusterSystem-akka.actor.default.dispatcher-4 or other 
>> number - I understand that it is related to my cluster (ClusterSystem) but 
>> not clear what it represents over here as there are multiple entries for it.
>> 2. In the above image most of the dispatchers are in yellow color, so 
>> does that mean that all the dispatchers are waiting? But, in my code I'm 
>> just passing message from one actor to other then what are they waiting for?
>>
>>
>> Could remoting be a hit over here? But, I'm using a single actor system 
>> for all the three actors...
>>
>>
>>
>>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.