the message comes from a clustered frontend service and I will not let the client to track the message seqNr for now. thanks
在 2014年5月16日星期五UTC+8下午10时31分24秒，Björn Antonsson写道： > > Hi, > > I'm not completely sure that I follow your last proposal, but if all of > this is in the same JVM and ActorSystem, then I would use the EventBus for > broadcasting to all the ConnectionActor instances. > > Can you let the clients keep track of their last received message number? > Then a ConnectionActor can be a plain Actor instead of an > EventsourcedProcessor. > > B/ > > On 15 May 2014 at 18:49:12, 何品 ([email protected] <javascript:>) wrote: > > Yes,I want to send the offline message.when the client connected in,the > persistenceChannel reset.and redeliver to the client,yes it's hard cause > the server may crash when I broadcast the message to the connectionActors > from their parent. > > but In my test,It okay,maybe not 100%,but acceptable for some times > crush.cause I first deliver message to connectionActors and then send the > response to the Play frontend. > > the problem is I have one ConnectionManagerActor and it has so many > children ConnectionActor, I want to send A broadcast message to all of > them,one connection Actor represent an android phone , > > and I don't want to create one if the android phone is not connected in. > > ConnectionManagerActor 1----->N ConnectionActor > > So I have to create all of them or using persistentChannel one for one? > deliever > I know that the message maybe loss when I sed them even they are in the > same VM.but cause the message are async sending ,so there maybe message > loss anyway right? > > And now I have switch to an different way,for the broadcast message,I want > to keep a sequence Number in ConnectionsManager,and a sequence Number in > the ConnectionActor too. > > when the client Connected it,it send an message to the > ConnectionsManagerActor with it current sequence Number,and the > ConnectionManagerActor send back it's current sequnce Number too. > > by this way the connection Actor will know how many message it need to > push now ,right? and then pull it. > > the workflow like this: > > 1 >> message to ConnectionsActor. > > 2 ConnectionsActor update broadcastMessage seqNr to seqNr+1,and then send > response to the frontpage. > > 3 Client connected in,ConnectionActor created ,and the current > broadcastMessage seqNr recovered cause it's EP. > > Then It send request to it's upstream actor,the ConnectionsManagerActor > ,for the current broadcastMessage seqNr. > > The ConnectionsManagerActor send the response ,assume its 6, to the > connectionActor. > > 4, The connection Actor received the message,and know it's 6 now ,but it's > 4(assumed) ,2 left.so it know how many and which message to retirve for > update. > > How do you think this way? > > Thank you very much,cause this is the first Time I using akka, cluster , > persistence with Play.it's really cool stuff ,you know.the cluster can > automatically heal . > > I just want say WOWOW !!!. > > I think this way be better ,and I just finish my redis plugin for > Play,cause I can not keep using EP as a database right? > > thanks for keeping me thinking. > > > > > > > > > > 在 2014年5月15日星期四UTC+8下午5时01分54秒，Björn Antonsson写道： >> >> Hi, >> >> Are you trying to make sure that if the server goes down, is restarted >> and a client reconnects, then it will get the messages that it was supposed >> to get when it was connected to the previous server instance? >> >> Or are you trying yo make sure that if a client disconnects from a server >> and then reconnects to the same server, it will get all the messages that >> where sent while it was disconnected? >> >> You also say that you want the clients to receive the messages once and >> only once, which is a hard thing to guarantee, since you can >> crash/disconnect at any time during your message sends to the client or >> during acknowledgement. How would you know for sure that the message is >> only delivered once? >> >> I think that it would be better if you explained what the Application is >> supposed to do (from a client and server perspective) instead of how you >> have implemented it right now. >> >> B/ >> >> On 14 May 2014 at 13:04:28, 何品 ([email protected]) wrote: >> >> Hi what I am trying to do is a push server,the actor path like this: >> >> /apps/:appId/connections/:connectionId >> >> the connectionId represent a single registered device,maybe connected via >> websocket or http or sockjs or tcp,so I have >> an abstraction socket actor here : >> >> /apps/:appId/connections/:connectionId/socket >> >> and when a client connected in with appId 1 and connectionId 1,with >> websocket.assume that I am using Play,so the websocket Actor path will be >> >> /system/websocket/:requestId/handler >> >> ,then the handler send an message to notify the actor system and register >> it,the connection actor now at : >> >> /apps/1/connections/1 ,will start the socket actor >> >> /apps/1/connections/1/socket,and the socket actor will reply the >> websocket handler actor a message with it's actorRef >> >> now the socket Actor know the websocket handler and the websocket know >> the socket handler >> >> seems as an binding at >> >> /apps/1/connections/1/socket <====> /system/websocket/:requestId/handler >> >> any message comes from the socket actor will go to the websocket handler >> ,and any message comes in will send to the socket actor >> >> the socket actor here just to keep my work more easier.Then here comes : >> >> I using an Persistente channel in the connection Actor,and it's actor >> path is: >> >> /apps/:appId/connections/:connectionId/channel >> >> and If a connection Actor receive a message from upstream,It will send >> the message via the persistent channel to deliver it to the socket Actor >> via it's path,when the client connected in, >> >> you know that,the socket actor will receive the message,and confirm >> it,the offline message will never receive again after the client has been >> received it. >> >> >> the message flow likes: >> web REST API >> | >> \|/ >> message >> >> | >> \|/ >> /apps actor >> >> | >> \|/ >> /apps/:appId actor >> >> | >> \|/ >> /apps/:appId/connections actor >> >> | >> \|/ >> /apps/:appId/connections/:connectionId actor >> >> | >> \|/ >> /apps/:appId/connections/:connectionId/channel persistent channel >> >> | >> \|/ >> /apps/:appId/connections/:connectionId/socket >> >> | >> \|/ >> /system/websocket/:requestId/handler >> >> | >> \|/ >> websocket client >> >> >> did that clear now? >> >> and the problem is the webAPI maybe send a message,that I should >> broadcast to all registered connection Actor,and maybe the connection Actor >> has not been startup now. >> So If I want the message to received by all the connection actor ,what >> should I do? >> >> for (connectionId : registeredConnections){ >> new channel for this Push operation >> send via channel >> } >> >> or just start up all the connection Actor and send them the message ,and >> after some idle time,stop the connection actor,cause some device may never >> connected in again. >> >> I want to keep that messages for an App ,will send at lest and at most >> once to the connection Actor,so it is >> >> /apps/:appId/connections actor >> >> | (1 ---- n) [send only once,and must be send] >> \|/ >> /apps/:appId/connections/:connectionId actor >> >> >> >> >> >> >> >> >> >> 在 2014年5月14日星期三UTC+8下午6时32分13秒，Björn Antonsson写道： >>> >>> Hi, >>> >>> I don't follow your question. The number of channels and actors are >>> only limited by your systems resources (Memory and Storage). >>> >>> What are you trying to achieve? What is it that you want to shut down? >>> >>> B/ >>> >>> On 13 May 2014 at 19:20:32, 何品 ([email protected]) wrote: >>> >>> I ,If I want to deliver a message to 1 million actor,could I create 1 >>> million Channel to send the message and then shutdown? >>> how about when the channel is persistent Channel? >>> >>> -- >>> >>>>>>>>>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> *Björn Antonsson* >>> Typesafe <http://typesafe.com/> – Reactive<http://reactivemanifesto.org/> >>> Apps >>> on the JVM >>> twitter: @bantonsson <http://twitter.com/#!/bantonsson> >>> >>> JOIN US. REGISTER TODAY! <http://www.scaladays.org/> >>> Scala <http://www.scaladays.org/> >>> Days <http://www.scaladays.org/> >>> June 16th-18th, <http://www.scaladays.org/> >>> Berlin <http://www.scaladays.org/> >>> >>> -- >> >>>>>>>>>> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> *Björn Antonsson* >> Typesafe <http://typesafe.com/> – Reactive<http://reactivemanifesto.org/> >> Apps >> on the JVM >> twitter: @bantonsson <http://twitter.com/#!/bantonsson> >> >> JOIN US. REGISTER TODAY! <http://www.scaladays.org/> >> Scala <http://www.scaladays.org/> >> Days <http://www.scaladays.org/> >> June 16th-18th, <http://www.scaladays.org/> >> Berlin <http://www.scaladays.org/> >> >> -- > >>>>>>>>>> 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 [email protected] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > > -- > *Björn Antonsson* > Typesafe <http://typesafe.com/> – Reactive <http://reactivemanifesto.org/> > Apps > on the JVM > twitter: @bantonsson <http://twitter.com/#!/bantonsson> > > JOIN US. REGISTER TODAY! <http://www.scaladays.org/> > Scala <http://www.scaladays.org/> > Days <http://www.scaladays.org/> > June 16th-18th, <http://www.scaladays.org/> > Berlin <http://www.scaladays.org/> > > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
