Thank you Endre for your reply. > Well, the ideal approach would be to have some API that has some asynchronous pull support, Does this mean a lean towards the JMS listener? It is by the spec an observer or a async pull based call. If that is the case,
> these should be isolated on a dedicated dispatcher with a dedicated thread (this is also necessary if the library relies on thread locals) I am not sure if JMS requires the implementations of these. As of now, I do have this setup as well. JMS listener -> Akka Stream for processing -> the actor in JMS listener I do have actor as the source getting sent the message in the onMessage call. And I wait on the actor for processing before taking the message off the queue by calling on session.commit(). A question I have is, how to have a transaction over those two threads - the actor and the queue, so to avoid duplicates? Thanks again for your help. On Friday, January 22, 2016 at 5:19:39 AM UTC-5, Akka Team wrote: > > Hi Watt, > > I personally think streams are a good fit to be used with processing > queues. The reasoning is that they apply and obey backpressure throughout > the entire pipeline you build providing good stability. On top of this, it > gives you a significant control about how you want to partition the > processing step into concurrent/parallel entities. > > > Is it recommended to use Akka to do polling and getting the message off > the queue or just use MessageListener that comes with the queue lib? > > Well, the ideal approach would be to have some API that has some > asynchronous pull support, i.e. you can ask for the next element and then > have a callback called once it becomes available. Push based interfaces, > that just call a callback on every arrival would defeat the purpose of > backpressure. Blocking pull, while not the nicest, is still acceptable > compromise for 3rd party APIs, but these should be isolated on a dedicated > dispatcher with a dedicated thread (this is also necessary if the library > relies on thread locals) > > > Is there any implication about thread safely and transactions across > threads between each approach? Thanks for your help. > > Any state that is wrapped in an actor or graph processing stage (as in, > they are hiding this from the external world, allowing modification only > through their exposed interfaces) will be safe as the actor model > implemented by Akka ensures proper serialized and memory safe access to > this state (see http://doc.akka.io/docs/akka/2.4.1/general/jmm.html). > > The only tricky part is if some library uses ThreadLocals since actors are > executed over a thread-pool and therefore not guaranteed to be executed on > the same thread for subsequent invocations. This can be circumvented by > creating a pool of such actor that wrap the ThreadLocal based API, and then > assign these to a PinnedDispatcher which will dedicate a thread for each of > the actors in this pool. > > -Endre > > On Thu, Jan 21, 2016 at 1:22 PM, Watt Poosanguansit <[email protected] > <javascript:>> wrote: > >> Hi, >> >> I do have a general question about pro and cons in using Akka and Akka >> stream in processing queues. I do have IBM JMS queue that I need to >> process. Is it recommended to use Akka to do polling and getting the >> message off the queue or just use MessageListener that comes with the queue >> lib? Is there any implication about thread safely and transactions across >> threads between each approach? Thanks for your help. >> >> >> >> >> -- >> >>>>>>>>>> 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 https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - Reactive apps on the JVM > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
