I like option 2, but I'm concerned there might be transaction issues with using several sessions.
I agree it would be good to sort this out properly. I know we don't do this often, but how about an IRC chat sometime this week, to see if we can get a single approach agreed? Paul On Mon, Nov 10, 2008 at 1:50 PM, Andreas Veithen <[EMAIL PROTECTED]> wrote: > In a polling model there are again two options: > > 1. One thread is responsible for the polling (i.e. executing > MessageConsumer#receive in a loop) and hands the received messages > over to a worker pool. > 2. Several threads execute MessageConsumer#receive (requires several > sessions) and messages are processed by the receiving thread. > > Option 1 is quite easy to implement in the current JMS transport, but > we would run into the same problem again. Option 2 easily solves the > problem but requires some substantial changes. > > Ideally we should improve the architecture of the JMS transport so > that we can plug in different strategies (see also my comments on the > patch proposed by Irantha), but this is not an easy task. > > Andreas > > On Mon, Nov 10, 2008 at 14:31, Paul Fremantle <[EMAIL PROTECTED]> wrote: >> My understanding is that most transaction JMS listeners (outside of >> EJB MDB containers) implement JMS listening as a polling model, so >> that they can (if necessary) start a transaction before reading the >> message. It seems to me that this is the simplest solution to this >> problem - switch from onMessage to a polling model. That way there is >> guaranteed a thread ready to read the message before the message >> starts to be read, rather than reading the message in onMessage and >> then getting a thread to deal with it. >> >> Paul >> >> On Mon, Nov 10, 2008 at 1:16 PM, Andreas Veithen >> <[EMAIL PROTECTED]> wrote: >>> Paul, >>> >>> In order to have the right behavior we need an ExecutorService (or >>> another thread pool implementation) with an execute method that blocks >>> until a worker thread becomes available. I don't see how to achieve >>> this with java.util.concurrent. Maybe somebody more familiar with this >>> can give a hint? >>> >>> Note that even if we can change the worker pool behavior in this way, >>> we still need to change the acknowledgement behavior: otherwise there >>> is still the risk of loosing the message that is waiting for a thread >>> to become available. >>> >>> Andreas >>> >>> On Mon, Nov 10, 2008 at 12:41, Paul Fremantle <[EMAIL PROTECTED]> wrote: >>>> Andreas >>>> >>>> I agree this is a serious problem and needs fixing. >>>> >>>> I can see three solutions: >>>> >>>> 1) Change the acknowledge behaviour >>>> 2) Add proper JMS transactions to the mix >>>> 3) Change the worker pool behaviour >>>> >>>> Of these I would prefer that we did (3) first and allowed (2) as an option. >>>> >>>> Can you elaborate on what the difficulties you saw in this were? >>>> >>>> Thx >>>> Paul >>>> >>>> On Sun, Nov 9, 2008 at 9:50 PM, Andreas Veithen >>>> <[EMAIL PROTECTED]> wrote: >>>>> I had a look into this problem some time ago, but it didn't appear to >>>>> me as a simple fix. >>>>> >>>>> Andreas >>>>> >>>>> On Fri, Nov 7, 2008 at 03:20, Sanjiva Weerawarana <[EMAIL PROTECTED]> >>>>> wrote: >>>>>> Andreas, isn't the fix a simple change to the transport? >>>>>> >>>>>> Andreas Veithen wrote: >>>>>>> >>>>>>> Danushka, >>>>>>> >>>>>>> Some time ago I opened SYNAPSE-435 which concludes that the JMS >>>>>>> transport in Synapse (now WS-Commons) is basically unreliable (as was >>>>>>> the JMS transport in Axis2 1.4). This is in contradiction with your >>>>>>> article. So either you used a different version of the transport, or >>>>>>> your article suggests a level of reliability that Synapse can't >>>>>>> provide, or my analysis in SYNAPSE-435 is incorrect. I would prefer >>>>>>> the latter (since this would imply that there is no issue at all), but >>>>>>> I fear that Synapse is not as reliable as the new sample would >>>>>>> suggest. Therefore, before including it, I think this needs to be >>>>>>> sorted out. Can you have a look at SYNAPSE-435 and give your opinion? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> PS: Just to avoid misunderstanding: I'm not criticizing your article >>>>>>> in any way. I think it is very well written and presents a highly >>>>>>> interesting use case. I just fear that Synapse can't keep the promises >>>>>>> made. >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 3, 2008 at 08:32, Danushka Menikkumbura <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Devs, >>>>>>>> It is possible to add message persistence to Synapse as explained in >>>>>>>> [1]. >>>>>>>> I think it is worth shipping this as an example. >>>>>>>> >>>>>>>> Danushka >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://wso2.org/library/articles/adding-persistence-synapse-queuing-model >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sanjiva Weerawarana, Ph.D. >>>>>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ >>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ >>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >>>>>> >>>>>> Blog: http://sanjiva.weerawarana.org/ >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Paul Fremantle >>>> Co-Founder and CTO, WSO2 >>>> Apache Synapse PMC Chair >>>> OASIS WS-RX TC Co-chair >>>> >>>> blog: http://pzf.fremantle.org >>>> [EMAIL PROTECTED] >>>> >>>> "Oxygenating the Web Service Platform", www.wso2.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> Paul Fremantle >> Co-Founder and CTO, WSO2 >> Apache Synapse PMC Chair >> OASIS WS-RX TC Co-chair >> >> blog: http://pzf.fremantle.org >> [EMAIL PROTECTED] >> >> "Oxygenating the Web Service Platform", www.wso2.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
