[akka-user] Re: Newbie: How to create actor on a cluster from a ClusterClient or another actor exterior to the cluster?

2017-07-10 Thread Ram K 


Arnout,


I have a single type of actor that I create that will be not be 
instantiated but available to instantiate on a server cluster, lets call, 
ClusterX. That cluster can have two seed nodes and grow from 1 to 1000 
member nodes. These actors will have a key-value pair as state and when the 
state gets updated, they publish the changed value to a topic that is 
specific to that actor’s key  and subscribed by, say, 10 other actors with 
their own key value pairs. They update their key value pairs based on an 
algorithm and immediately publish to topics linked to their state keys. 
This chain process only stops when there are no more subscribers left.


The first in chain actor who got his state updated, is from external server.


The way I designed from what I read from your documentation is to use 
ClusterClient on external server, where an actor gets instatiated and gets 
ClusterClient and uses that to ‘tell’ ClusterReceptionist lying on seed 
nodes. I made sure the code of each of my actors on the 1-1000 member 
cluster nodes register themselves with the ClusterReceptionist as soon as 
they get instantiated. So I thought, ClusterClient on external (external to 
ClusterX) server ‘tell’s ClusterReceptionist with a key-value and 
ClusterReceptionist, which knows the registered actor (by the key of the 
state), will send it to him.


For me, the problem was ClusterReceptionist is a bottleneck because 
ClusterClient can only send to particular remote host (a seed node) on the 
clusterX. I am looking for a better way to be able to scale the ‘tell’-ing 
of the key-value pairs to Cluster Receptionist. 


Also, I could not figure out if I create the Actor on seed node, will it be 
rebalanced to another shard on a member node of ClusterX? 


Should not there be a better way for external server’s ClusterClient to 
create node agnostic way, Actors, that will be properly balanced and 
locations identified when further ‘tell’s need to be told?


Or am I thinking the whole thing wrong?


1. I need actors created from external requests without having to know 
where they are being created.

2. The actors also need to be receiving messages from external(external to 
Cluster they are in) programs without having to maintain a registry of the 
actors external to the cluster.


I also need persistence with cluster sharing because of all the rebalancing 
stuff.


Ram

On Monday, July 10, 2017 at 1:41:46 AM UTC-4, Ram K wrote:
>
> I have tried ActorSelection etc but it requires a host IP to be given 
> where the actor will be created.
>
> I have used ClusterClient with ClusterReceptionist on each node to send 
> messages to the destination actors but could not find anything in AKKA 
> documentation about a facility that will take request to create a specific 
> actor and create somewhere on the cluster without the original requestor 
> having to bother where it needs to be created or moved to.
>
> For my purposes I am using ClusterSharding with persistence and two seed 
> nodes and ClusterReceptionist on all nodes.
>
>
> Ram
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-streams] Generic streams and abstract types

2017-07-10 Thread Jeff 
Any thoughts?

On Thursday, July 6, 2017 at 2:23:50 PM UTC-7, Jeff wrote:
>
> Here is a strawman program which illustrates the issue I am having
>
> trait RequestBuilder {
>   type Out
>
>   def complete(p: Promise[Out]): Unit
> }
>
> def makeRequest(in: RequestBuilder): Source[(RequestBuilder, 
> Promise[in.Out]), Future[in.Out]] = {
>   val p = Promise[in.Out]
>
>   Source.single(in -> p).mapMaterializedValue(_ => p.future)
> }
>
> val sink = MergeHub.source[(RequestBuilder, Promise[???])].to(Sink.foreach {
>   case (r, p) => r.complete(p)
> }).run()
>
> sink.runWith(makeRequest(new RequestBuilder {
>   type Out = Int
>
>   def complete(p: Promise[Out]): Unit = p.success(1)
> }))
>
>
> The issue is, how do I type the Promise[???]  in the sink? I have been 
> able to work around this by making the Promise a part of the RequestBuilder 
> trait itself, but this seems like a code smell to me
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka-Http Entity Stream Truncation

2017-07-10 Thread 'Michael Pisula' via Akka User List 
Hi Johannes,
perfect, thanks for the insight. I think we can work with that.

Cheers,
Michael

Am Montag, 10. Juli 2017 16:55:55 UTC+2 schrieb johannes...@lightbend.com:
>
> Hi Michael,
>
> On Monday, July 10, 2017 at 9:01:00 AM UTC+2, Michael Pisula wrote:
>>
>> As far as I saw from the source code, it could point to a problem with 
>> header parsing, but I am not exactly sure what could cause the problem.
>>
>
> The place in the code is actually misleading, as it the error is only 
> prepared at that place after all headers have been read. The error will 
> only be reported, however, only later on if the connection is closed while 
> there's still data expected on the connection. That will be the case if a 
> `Content-Length` was specified but less than the given number of bytes was 
> read before the connection was closed, or if `chunked` transfer encoding 
> was used, if the connection was closed before the final empty chunk was 
> sent.
>
> You could set `akka.http.server.log-unencrypted-network-bytes = 1000` to 
> see all data that was sent on the connection which might help with 
> debugging the issue.
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Typed and MDC

2017-07-10 Thread Konrad “ktoso” Malawski 
The "power mode” ;-)


On 11 July 2017 at 00:02:12, Justin du coeur (jduco...@gmail.com) wrote:

Oh, sweet -- ExtensibleBehavior looks enormously useful...

On Mon, Jul 10, 2017 at 9:29 AM, Konrad 'ktoso' Malawski 
wrote:

> Once I wrote the response I though that for using the library directly
> you'll also want to know about the possibility to implement:
>
>
> /**
>  * Extension point for implementing custom behaviors in addition to the 
> existing
>  * set of behaviors available through the DSLs in 
> [[akka.typed.scaladsl.Actor]] and [[akka.typed.javadsl.Actor]]
>  */
> abstract class ExtensibleBehavior[T] extends Behavior[T] {
>   /**
>* Process an incoming [[Signal]] and return the next behavior. This means
>* that all lifecycle hooks, ReceiveTimeout, Terminated and Failed messages
>* can initiate a behavior change.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveSignal(ctx: ActorContext[T], msg: Signal): Behavior[T]
>
>   /**
>* Process an incoming message and return the next behavior.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveMessage(ctx: ActorContext[T], msg: T): Behavior[T]
>
> }
>
>
> In which way you should be able to "wrap" any other behaviour and to the
> MDC clear in the right place hm...
>
> Anyway, like I said, not a solved problem yet.
>
> -- Konrad
> --
> >> 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 https://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 a topic in the
Google Groups "Akka User List" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/akka-user/TmzMVgZjdnU/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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Typed and MDC

2017-07-10 Thread Justin du coeur 
Oh, sweet -- ExtensibleBehavior looks enormously useful...

On Mon, Jul 10, 2017 at 9:29 AM, Konrad 'ktoso' Malawski 
wrote:

> Once I wrote the response I though that for using the library directly
> you'll also want to know about the possibility to implement:
>
>
> /**
>  * Extension point for implementing custom behaviors in addition to the 
> existing
>  * set of behaviors available through the DSLs in 
> [[akka.typed.scaladsl.Actor]] and [[akka.typed.javadsl.Actor]]
>  */
> abstract class ExtensibleBehavior[T] extends Behavior[T] {
>   /**
>* Process an incoming [[Signal]] and return the next behavior. This means
>* that all lifecycle hooks, ReceiveTimeout, Terminated and Failed messages
>* can initiate a behavior change.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveSignal(ctx: ActorContext[T], msg: Signal): Behavior[T]
>
>   /**
>* Process an incoming message and return the next behavior.
>*
>* The returned behavior can in addition to normal behaviors be one of the
>* canned special objects:
>*
>*  * returning `stopped` will terminate this Behavior
>*  * returning `same` designates to reuse the current Behavior
>*  * returning `unhandled` keeps the same Behavior and signals that the 
> message was not yet handled
>*
>* Code calling this method should use [[Behavior$]] `canonicalize` to 
> replace
>* the special objects with real Behaviors.
>*/
>   @throws(classOf[Exception])
>   def receiveMessage(ctx: ActorContext[T], msg: T): Behavior[T]
>
> }
>
>
> In which way you should be able to "wrap" any other behaviour and to the
> MDC clear in the right place hm...
>
> Anyway, like I said, not a solved problem yet.
>
> -- Konrad
>
> --
> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Stream deduping

2017-07-10 Thread Shiva Ramagopal 
Hi,

Thanks for the answers!

Michal,

Your approach seems most appropriate for my case as it dedups *and* handles
late records. Your point on losing messages in the map upon restart after a
failure, is very valid. One way of handling this is to have checkpoints at
window-level.

Roughly speaking, if my dedup window is some X seconds to allow for
late-arriving messages that are utmost X seconds late, the map will have
two windows - the current or Nth window and the previous or (N-1)th window,
and possibly also a (N-2)th window to not miss messages that arrive exactly
X seconds late. A periodic source could read the (N-2)th window's contents
and write them to the sink and checkpoint the corresponding Kafka offsets
and the corresponding timestamps. Now, if the process fails, the lost
messages are those in the Nth and (N-1)th windows.

When restarting after a failure, the process starts reading from the offset
corresponding to the (N-1)th window. I should be testing carefully, but I
guess this could work.

Thanks again!
-Shiv

On Sat, Jun 24, 2017 at 9:03 PM, Michal Borowiecki <
michal.borowie...@openbet.com> wrote:

> I drafted an implementation outline in kafka-streams to address the
> problem of sliding-window reordering (to cater for late messages within the
> time window), it also caters for de-duplication:
>
> https://stackoverflow.com/questions/43939534/apache-
> kafka-order-windowed-messages-based-on-their-value/44345374#44345374
>
> You can implement something similar in akka-streams I believe.
>
> First thing that comes to mind is to sink messages into a sorted map
> (keyed by event-time timestamp and msg key pair) and then a new periodic
> source picks them up - and connect the two with a Flow.fromSinkAndSource.
> You'll need to take care of offset commits - after the windowing
> de-duplication stage, i.e. on restart you don't want to lose the messages
> buffered in the map.
>
> Looking forward to ideas how to do this better.
>
> Cheers,
>
> Michał
>
> On 23/06/17 17:42, Shiva Ramagopal wrote:
>
> Hi,
>
> I'm looking for the latest and greatest techniques and thoughts in stream
> deduplication and would love to know if anyone here has done this at scale.
> Specifically, I'm looking for deduping that also handles late-arriving
> messages.
>
> In the past few days of my search, I've mostly come across ideas and
> implementations like
>
> - Batching the stream based on time windows (non-overlapping) and deduping
> within the batch
> - Possible improvements on the above technique using overlaping time
> windows
> - HDFS-specific cases where a stream is consumed (pretty batchy), written
> to HDFS and deduped there
>
> My source is Kafka, if that helps.
>
> Thanks
> Shiv
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
>  Michal Borowiecki
> Senior Software Engineer L4
> T: +44 208 742 1600
>
>
> +44 203 249 8448
>
>
>
> E: michal.borowie...@openbet.com
> W: www.openbet.com
> OpenBet Ltd
>
> Chiswick Park Building 9
>
> 566 Chiswick High Rd
>
> London
>
> W4 5XT
>
> UK
> 
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmas...@openbet.com and delete it from your system as well as any
> copies. The content of e-mails as well as traffic data may be monitored by
> OpenBet for employment and security purposes. To protect the environment
> please do not print this e-mail unless necessary. OpenBet Ltd. Registered
> Office: Chiswick Park Building 9, 566 Chiswick High Road, London, W4 5XT,
> United Kingdom. A company registered in England and Wales. Registered no.
> 3134634. VAT no. GB927523612
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka-Http Entity Stream Truncation

2017-07-10 Thread johannes . rudolph 
Hi Michael,

On Monday, July 10, 2017 at 9:01:00 AM UTC+2, Michael Pisula wrote:
>
> As far as I saw from the source code, it could point to a problem with 
> header parsing, but I am not exactly sure what could cause the problem.
>

The place in the code is actually misleading, as it the error is only 
prepared at that place after all headers have been read. The error will 
only be reported, however, only later on if the connection is closed while 
there's still data expected on the connection. That will be the case if a 
`Content-Length` was specified but less than the given number of bytes was 
read before the connection was closed, or if `chunked` transfer encoding 
was used, if the connection was closed before the final empty chunk was 
sent.

You could set `akka.http.server.log-unencrypted-network-bytes = 1000` to 
see all data that was sent on the connection which might help with 
debugging the issue.

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka Typed and MDC

2017-07-10 Thread Konrad 'ktoso' Malawski 
Once I wrote the response I though that for using the library directly 
you'll also want to know about the possibility to implement:


/**
 * Extension point for implementing custom behaviors in addition to the existing
 * set of behaviors available through the DSLs in [[akka.typed.scaladsl.Actor]] 
and [[akka.typed.javadsl.Actor]]
 */
abstract class ExtensibleBehavior[T] extends Behavior[T] {
  /**
   * Process an incoming [[Signal]] and return the next behavior. This means
   * that all lifecycle hooks, ReceiveTimeout, Terminated and Failed messages
   * can initiate a behavior change.
   *
   * The returned behavior can in addition to normal behaviors be one of the
   * canned special objects:
   *
   *  * returning `stopped` will terminate this Behavior
   *  * returning `same` designates to reuse the current Behavior
   *  * returning `unhandled` keeps the same Behavior and signals that the 
message was not yet handled
   *
   * Code calling this method should use [[Behavior$]] `canonicalize` to replace
   * the special objects with real Behaviors.
   */
  @throws(classOf[Exception])
  def receiveSignal(ctx: ActorContext[T], msg: Signal): Behavior[T]

  /**
   * Process an incoming message and return the next behavior.
   *
   * The returned behavior can in addition to normal behaviors be one of the
   * canned special objects:
   *
   *  * returning `stopped` will terminate this Behavior
   *  * returning `same` designates to reuse the current Behavior
   *  * returning `unhandled` keeps the same Behavior and signals that the 
message was not yet handled
   *
   * Code calling this method should use [[Behavior$]] `canonicalize` to replace
   * the special objects with real Behaviors.
   */
  @throws(classOf[Exception])
  def receiveMessage(ctx: ActorContext[T], msg: T): Behavior[T]

}


In which way you should be able to "wrap" any other behaviour and to the 
MDC clear in the right place hm...

Anyway, like I said, not a solved problem yet.

-- Konrad

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka Typed and MDC

2017-07-10 Thread Konrad 'ktoso' Malawski 
Akka Typed is still not quite "done" so missing or undecided upon APIs may 
still be here and there.
That's one of them, so I opened a ticket to discuss and decide what to do 
about it in Typed.

https://github.com/akka/akka/issues/23326

Having that said, you can always just directly use the logging library that 
you're using (and in fact this may be what we'll end up recommending with 
Typed... we'll see).

-- Konrad

On Saturday, July 8, 2017 at 4:15:01 AM UTC+9, Qux wrote:
>
> Hi,
>
> Whats the best way to get a DiagnosticActorLogging for Typed Actors?
>
> For untyped Actors we have this:
>
> public abstract class ActorBase extends AbstractActor {
> protected final DiagnosticLoggingAdapter logger = Logging.getLogger(this);
>
>
> @Override
> public void aroundReceive(PartialFunction receive, 
> Object msg) {
> try {
> ActorLoggingHelper.setMdc(msg, logger);
> super.aroundReceive(receive, msg);
> } finally {
> ActorLoggingHelper.clearMdc(logger);
> }
> }
> }
>
>
> Would be great if something similar is possible for the new Typed Actors 
> as well.
>
> Samuel
>

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Newbie: How to create actor on a cluster from a ClusterClient or another actor exterior to the cluster?

2017-07-10 Thread Arnout Engelen 
Hello Ram,

ClusterClient/ClusterReceptionist are relatively low-level tools.

I see you're already familiar with Cluster Sharding. Wouldn't that be a
possible solution for "creating an actor somewhere on the cluster without
the original requestor having to bother where it needs to be created"?

If not, could you explain your situation in a bit more detail?


Kind regards,

Arnout

On Sun, Jul 9, 2017 at 8:47 PM, Ram K  wrote:

> I have tried ActorSelection etc but it requires a host IP to be given
> where the actor will be created.
>
> I have used ClusterClient with ClusterReceptionist on each node to send
> messages to the destination actors but could not find anything in AKKA
> documentation about a facility that will take request to create a specific
> actor and create somewhere on the cluster without the original requestor
> having to bother where it needs to be created or moved to.
>
> For my purposes I am using ClusterSharding with persistence and two seed
> nodes and ClusterReceptionist on all nodes.
>
>
> Ram
>
> --
> >> 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 https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Arnout Engelen
*Senior Software Engineer*
E: arnout.enge...@lightbend.com
T: https://twitter.com/raboofje

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Alpakka S3: errors when uploading on a slow connection

2017-07-10 Thread Vasiliy Levykin 
Hello,

I'm using alpakka 0.10, akka 2.5.3.

When using S3 multiUpload on a slow connection, I'm getting an error 
sometimes:

java.lang.RuntimeException: Cannot find etag
  at 
akka.stream.alpakka.s3.impl.S3Stream.$anonfun$chunkAndRequest$5(S3Stream.scala:218)
  at scala.Option.getOrElse(Option.scala:121)
  at 
akka.stream.alpakka.s3.impl.S3Stream.$anonfun$chunkAndRequest$1(S3Stream.scala:218)
  at akka.stream.impl.fusing.Map$$anon$7.onPush(Ops.scala:47)
  at 
akka.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:499)
  at 
akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:462)
  at 
akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:368)
  at 
akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:571)
  at 
akka.stream.impl.fusing.GraphInterpreterShell$AsyncInput.execute(ActorGraphInterpreter.scala:457)
  at 
akka.stream.impl.fusing.GraphInterpreterShell.processEvent(ActorGraphInterpreter.scala:546)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:725)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:740)
  at akka.actor.Actor.aroundReceive(Actor.scala:513)
  at akka.actor.Actor.aroundReceive$(Actor.scala:511)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:650)
  at akka.actor.ActorCell.receiveMessage(ActorCell.scala:527)
  at akka.actor.ActorCell.invoke(ActorCell.scala:496)
  at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
  at akka.dispatch.Mailbox.run(Mailbox.scala:224)
  at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
  at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
  at 
akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
  at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
  at 
akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

After digging a bit, I found that the response is 400 Bad request with



  RequestTimeout
  Your socket connection to the server was not read from or 
written to within the timeout period. Idle connections will be 
closed.
  ...
  ...



Sometimes there is another error, I haven't explored that yet, but might be 
related:

akka.http.impl.engine.client.OutgoingConnectionBlueprint$UnexpectedConnectionClosureException:
 
The http server closed the connection unexpectedly before delivering 
responses for 1 outstanding requests
  at 
akka.http.impl.engine.client.OutgoingConnectionBlueprint$.$anonfun$apply$6(OutgoingConnectionBlueprint.scala:123)
  at 
akka.http.impl.engine.client.OutgoingConnectionBlueprint$.$anonfun$apply$6$adapted(OutgoingConnectionBlueprint.scala:123)
  at 
akka.http.impl.util.One2OneBidiFlow$One2OneBidi$$anon$1$$anon$4.onUpstreamFinish(One2OneBidiFlow.scala:96)
  at 
akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:484)
  at 
akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:368)
  at 
akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:571)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter$SimpleBoundaryEvent.execute(ActorGraphInterpreter.scala:42)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter$SimpleBoundaryEvent.execute$(ActorGraphInterpreter.scala:38)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter$BatchingActorInputBoundary$OnComplete.execute(ActorGraphInterpreter.scala:67)
  at 
akka.stream.impl.fusing.GraphInterpreterShell.processEvent(ActorGraphInterpreter.scala:546)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:725)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:740)
  at akka.actor.Actor.aroundReceive(Actor.scala:513)
  at akka.actor.Actor.aroundReceive$(Actor.scala:511)
  at 
akka.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:650)
  at akka.actor.ActorCell.receiveMessage(ActorCell.scala:527)
  at akka.actor.ActorCell.invoke(ActorCell.scala:496)
  at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
  at akka.dispatch.Mailbox.run(Mailbox.scala:224)
  at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
  at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
  at 
akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
  at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
  at 
akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)


Could you please recommend what to tune or how to work around this?

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

[akka-user] Akka-Http Entity Stream Truncation

2017-07-10 Thread 'Michael Pisula' via Akka User List 
Hi guys,

Long time no see :-)

We seeing a strange exception in the logs of our new Akka Http app in 
production. The Exception is an EntityStreamException with the cause 
message "entity stream truncation". I could not find any helpful 
information regarding that exception here in the list or in the github 
issues. As far as I saw from the source code, it could point to a problem 
with header parsing, but I am not exactly sure what could cause the 
problem. Would be really grateful for a pointer.

Cheers,
Michael

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.