Re: [akka-user] Akka Cluster with different seed node sequence

[prateek singhal]

Thanks Konrad and Patrik.

Thanks for clearing my doubt.

On Thursday, 5 October 2017 00:18:55 UTC+5:30, Patrik Nordwall wrote:
>
> Konrad is right, that is not what you want.
>
> I’d like to add two things. You don’t have to start the node listed first 
> in seed-nodes before other nodes. It’s fine to start it afterwards or at 
> the same time.
>
> Before joining itself the first seed node tries to join other seed nodes, 
> and that might be why you see it working with your setup, but it’s asking 
> for trouble and no advantage. The purpose of trying other nodes is so that 
> the first can be restarted and join existing cluster.
>
> /Patrik
> ons 4 okt. 2017 kl. 20:11 skrev Konrad “ktoso” Malawski <
> konrad@lightbend.com >:
>
>> Hi Prateek,
>> No, this is a misunderstanding of how seed-nodes work.
>>
>> The first node in that list MUST be the same node if using the seed-nodes 
>> process.
>>
>> What you did by making each node have it’s own address as the first in 
>> their seed node list is form 3 independent clusters.
>> This works as intended; The first node in this list must be the same on 
>> all nodes, only for the need of consistency of the initial cluster creation.
>>
>> A node which sees “oh, I’m the first node in the seed nodes list” will 
>> join “itself” and form the cluster.
>> This is why the first node in the list is special. The other’s order does 
>> not matter; The first one has to be the same though.
>>
>>
>> —
>> Konrad `kto.so` Malawski
>> Akka  @ Lightbend 
>>
>> On 4 October 2017 at 11:08:31, prateek singhal (prateek...@gmail.com 
>> ) wrote:
>>
>> Hi, 
>>
>> As per the documentation under cluster seed nodes (
>> https://doc.akka.io/docs/akka/2.5.4/scala/cluster-usage.html#joining-to-seed-nodes),
>>  
>> We can start seed node in any sequence, but the node configured as the 
>> first element in seed-nodes configuration list must be started when 
>> initially starting a cluster.
>>
>> In my case I have 3 servers with following seed-codes configuration
>>
>> Server A : (host1:2552)
>> akka.cluster.seed-nodes = ["akka.tcp://ClusterSystem@host1:2552", 
>> "akka.tcp://ClusterSystem@host2:2552", 
>> "akka.tcp://ClusterSystem@host3:2552"]
>>
>> Server B : (host2:2552)
>> akka.cluster.seed-nodes = ["akka.tcp://ClusterSystem@host2:2552", 
>> "akka.tcp://ClusterSystem@host3:2552", 
>> "akka.tcp://ClusterSystem@host1:2552"]
>>
>> Server C  : (host3:2552)
>> akka.cluster.seed-nodes = ["akka.tcp://ClusterSystem@host3:2552", 
>> "akka.tcp://ClusterSystem@host1:2552", 
>> "akka.tcp://ClusterSystem@host2:2552"]
>>
>>
>> First element of seed-nodes list of each server is its own address, In 
>> this way i don't have to start particular server first when initially 
>> starting a cluster, I can start any of the 3 server of seed-node list in 
>> any order irrespective of which one is first element.
>>
>> Configuration for rest of the node in cluster:
>> Server D : (host4:2552)
>> akka.cluster.seed-nodes = ["akka.tcp://ClusterSystem@host1:2552", 
>> "akka.tcp://ClusterSystem@host2:2552", 
>> "akka.tcp://ClusterSystem@host3:2552"]
>>
>> Is above configuration and understanding is correct or it will create 
>> different cluster island.
>>
>> 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+...@googlegroups.com .
>> To post to this group, send email to akka...@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+...@googlegroups.com .
>> To post to this group, send email to akka...@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 

[akka-user] Re: RestartSource/Flow/Sink practical examples

[Jeff]

Still trying to figure out how I can use the new RestartSink/Flow/Source to 
retry an Http request in a Stream. Any thoughts?

On Thursday, October 5, 2017 at 12:29:07 PM UTC-7, Jeff wrote:
>
> I am trying to create a polling flow which feeds the results of the last 
> update into the next update (much like the SSE example here 
> https://youtu.be/-7OyuTMgI1I). However, I'd like to add an exponential 
> backoff on failed requests. The new RestartSource/Flow/Sink seems like the 
> correct fit, however I can't seem to get it to work in practice. The 
> strawman example I have is 
>
> val flow = Flow[Long].mapAsyncUnordered(1) { lastIndex =>
>
>   val request = RestartFlow.withBackoff(1.second, 10.seconds, .20)(() => {
> Flow[Long].mapAsyncUnordered(1) { lastIndex =>
>   val p = Promise[WatchResult]
>   pool ! HAConnectionPool.Watch(lastIndex, p)
>   p.future
> }
>   })
>
>   Source.repeat(lastIndex).via(request).runWith(Sink.head)
> }
>
>
> The problem with this however is that mapAsyncUnordered() will always 
> pull the upstream when the future completes, even if there is no downstream 
> demand, causing 2 requests to be made instead of one. I thought about using 
> RestartSource, but it appears that it will keep resetting the 
> Source.single on completeStage(), which is undesirable. 
>
> Thoughts?
>
>

-- 
>>  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] Ask not working if Future is used in receive partial method

[Alexey Shuksto]

Hi there,

It's prohibited to leak and close over actor internals. In your case Future not 
only closes over 'sender()', which is very bad and causes timeout (cause by the 
time future is complete sender() is null), you also modify actor internal state 
inside it, assigning to 'student', which is just horrible. 

In your example there us no need for Future at all. If you try to model some 
prolonged action, you should fix your sender by 'val reply = sender()' before 
Future invocation and send results after it back to sender and self, to update 
your student. 

-- 
>>  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] Ask not working if Future is used in receive partial method

[Danny Lesnik]

I have the following stateful Actor

class StudentActor extends Actor with ActorLogging{
 
  var student:Student = Student(id,firstName,lastName)

  implicit val executionContext = Try {
context.system.dispatchers.lookup("blocking-code-dispatcher")
  }.getOrElse(context.system.dispatcher)


  override def receive = {

case UpdateStudent(_, c) =>
  Future[Student] {

val updatedStudent = student.copy(counter = student.counter + c)
student = updatedStudent
log.info(sender().toString())
updatedStudent
  }(executionContext).map(updatedStudent => sender() ! updatedStudent)

case GetStudent(id,_) => sender() ! student

  }
}



When I try to use ask pattern to update this student from main method, I'm 
receiving timeout 


holder.ask(UpdateStudent("1")).mapTo[Student].foreach(println(_))


However, if I remove Future method and using the following code it works like 
charm:


  case UpdateStudent(_, c) =>val updatedStudent = student.copy(counter 
= student.counter + c)

student = updatedStudent
log.info(sender().toString())
updatedStudent

sender() ! updatedStudent


Why using Future in partial method causes ask timeout? 

I believe this is something stupid, but I can't figure it out :) 

-- 
>>  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: Multi-DC Clustering & Distributed Data

[Johan Andrén]

Hi Jeroen,

I saw now that you already commented on the ticket, but for completeness 
sake:

All nodes still participate in the same DD (unless you limit with 
akka.cluster.distributed-data.role)

We have ideas for optimising the gossip so that less inter-DC gossip 
happens, between fewer cross-DC pairs but nothing is implemented yet. 
Tracked by issue: https://github.com/akka/akka/issues/23249

--
Johan
Akka Team

On Monday, October 2, 2017 at 9:20:51 AM UTC+2, Jeroen Gordijn wrote:
>
> Hi,
>
> I read the release notes of 2.5.6 and saw the Multi-DC Clustering 
> 
>  
> which looks interesting. Going through the doc I see information about 
> Cluster Singleton and Cluster Sharding and how it behaves with this new 
> feature. I'm using Distributed Data and I am wondering if there are any 
> changes for that?
>
> More specific:
>
>- Do all nodes in all DC's still participate in the same DD, or is it 
>a DD set per DC?
>- If they still gossip all data to all nodes in all DC's: 
>- Is there a change in the gossip interval that differs between within 
>   DC and over DC?
>   - Do all nodes gossip to other DC? Or is it like the described in 
>   the failure detection that only the oldest nodes do it?
>   - Currently the gossip prefers reachable over unreachable nodes, 
>   does this now take unreachable DC into account?
>- Do you have any other info I missed with the questions above?
>
>
> Thanks in advance!
>
> Cheers,
>
> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Akka http - dispatch on request content type

[Johan Andrén]

The "normal" way would be to have the same logic, but different 
unmarshalling, and this the unmarshalling infra takes care of, you'd use 
the entity directive 
https://doc.akka.io/docs/akka-http/10.0.10/scala/http/routing-dsl/directives/marshalling-directives/entity.html
 
and pass a super-marshaller created by passing the supported marshalers to 
`Unmarshalling.firstOf(json, text, binary)`. This isn't super obvious from 
the docs so there are some possible improvements here.

Here is a working sample that does exactly 
this: https://gist.github.com/johanandren/ab4b2df05004399298e900776690a0de

If you are not interested in this but actually want different logic to 
happen depending on the content type, then extracting the content type and 
matching is probably the way to go, note that you should still be able to 
make use of the unmarshalling infra for the individual sub-routes to get 
character encoding automagically handled.

--
Johan
Akka Team


On Monday, October 9, 2017 at 9:45:08 PM UTC+2, kr...@humio.com wrote:
>
> Hi,
>
> I've been trying to find an example that illustrates how to write a route 
> that follows different paths based on the Content-Type of a request.
>
> Clearly, I can extract the value of the "Content-Type" header, but then 
> there is the charset and everything to worry about in the resulting value.
>
> Basically I want to have a post { ... } rule, that do three different 
> things if the incoming data is text/plain (split it by newlines), 
> application/json (parse it as such). In both cases I would want to 
> unmarshall the data in the charset given by the client.  A third rule would 
> match the binary type application/x-vnd-foo would parse the incoming data 
> from ByteString.
>
> So how do I use all the akka niceties to write this "case statement" with 
> 3 different part-routes without having to extract and match the strings?
>
> The world seems to be full of examples of how to match 'Accept' rules to 
> response content types in akka, but nothing easy to find on the incoming 
> case.
>
> Thanks,
>
> Kresten
>
>

-- 
>>  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: HTTP Host Connection Pool

[Johan Andrén]

That seems to be an oversight, please open a ticket in the Akka HTTP issue 
tracker about the missing newHostConnectionPool variant that takes a 
ConnectionPoolSettings, thanks!

--
Johan
Akka Team

On Wednesday, October 11, 2017 at 1:42:34 PM UTC+2, Yoad Gidron wrote:
>
> I have been trying to use Akka HTTP Host Connection Pool in Java. 
> akka.http.javadsl.Http 
> class has 3 different signatures for the cachedHostConnectionPool() method. 
> After straggling with it for a while, I realised that one of these method 
> is using HTTPS, while the other 2 are using HTTP. There is nothing in the 
> method name or signature that implies that. Also, it ignores the protocol 
> that is defined in the ConnectHttp parameter. I find it strange, but maybe 
> I am missing something. 
> The issue is that only the HTTPS variant takes a ConnectionPoolSettings 
> parameter, so how would you control the settings for HTTP? Is it only in 
> configuration?  
>

-- 
>>  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 | Work - Pull pattern running into problem !

[Justin du coeur]

Yeah -- this approach (which is fairly common) tends to mask the underlying
problem until things get a little more pathological, and then you just get
a bigger explosion...

On Thu, Oct 12, 2017 at 4:20 PM, Bwmat  wrote:

> If, on average, your producers Don't outrun your producers, and only do so
> in limited bursts, you could try storing some of the buffered data on disk,
> until the burst is over?
>
> Hard to imagine it would be reliable though
>
> --
> >>  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] Implements CRDTs conters more than 100 000

[Johan Andrén]

>
> I have a big tree of business objects each of them contain counter and 
> threshold when threshold reach then object change its state.


This may also be a reason why Distrubed Data isn't a perfect fit to your 
problem, the CRDTs are eventually consistent, that means that the counter 
could have +n added separately on every node of your cluster but the other 
nodes does not see this right away, if you want to make sure you act on the 
threshold being reached only once and act differently for all requests 
after that it will not be possible with Distriubted Data but you would 
rather need to represent each entity as an actor (perhaps together with 
sharding) to achieve consistency.

--
Johan
Akka Team

On Thursday, October 12, 2017 at 10:04:06 PM UTC+2, Patrik Nordwall wrote:
>
> Might be some misunderstanding of terminology here. The quote from the 
> documentation is about Distributed Data. In last post I read it as you talk 
> about an actor tree. Anyway, in distributed Data you would use many 
> ORCounterMap as top level entries, and each such map would hold a number of 
> named counters. E.g. 1 maps with 100 counters each. If it actually 
> scales to these numbers is something you have to try.
>
> /Patrik
> tors 12 okt. 2017 kl. 15:08 skrev Hsnamed :
>
>> Yes , i saw that limitation and yes i have 1m top entities.  As example , 
>> there are four level of tree
>>
>> 1 - Category of markets groups
>> 2 - Markets group
>> 3 - Market - eg. Derivative
>> 4 - selection in market 
>>
>> Each market may have one or more positions .
>> If counter of selection reaches threshold - position change the state e.g 
>> diactivated
>>
>> I think about it as create actor system which equals the tree, because 
>> increments must be ordered  in selection context.
>>
>>
>>
>>
>>
>> четверг, 12 октября 2017 г., 15:41:14 UTC+3 пользователь Konrad Malawski 
>> написал:
>>>
>>> It’s as the docs explain: 
>>>
>>> It is not intended for *Big Data*. The number of top level entries 
>>> should not exceed 10. When a new node is added to the cluster all these 
>>> entries are transferred (gossiped) to the new node. The entries are split 
>>> up in chunks and all existing nodes collaborate in the gossip, but it will 
>>> take a while (tens of seconds) to transfer all entries and this means that 
>>> you cannot have too many top level entries. The current recommended limit 
>>> is 10. We will be able to improve this if needed, but the design is 
>>> still not intended for billions of entries.
>>> It depends on your data architecture though.
>>> Are you sure it would be 1 million actual top level entries?
>>>
>>> -- 
>>> Cheers,
>>> Konrad 'ktoso ' Malawski
>>> Akka  @ Lightbend 
>>>
>>> On October 12, 2017 at 21:24:37, Hsnamed (hsn...@gmail.com) wrote:
>>>
>> Hello, how can i implement 1 million CRDTs counters to use akka without 
>>> big disadvantage ? 
>>>
>>> I have a big tree of business objects each of them contain counter and 
>>> threshold when threshold reach then object change its state.
>>>
>>> Tree have more than 1 million objects. Does it possible to implements 
>>> using akka ? 
>>>
>>> Thanks for advices.
>>>
>>> --
>>> >> 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 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.
>>
>

-- 
>>  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