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]
