synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Re: [SUGGESTION] New Sample
Date Mon, 10 Nov 2008 15:59:29 GMT
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
<andreas.veithen@gmail.com> 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 <pzfreo@gmail.com> 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
>> <andreas.veithen@gmail.com> 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 <pzfreo@gmail.com> 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
>>>> <andreas.veithen@gmail.com> 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 <sanjiva@opensource.lk>
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 <danushka@wso2.com>
>>>>>>> 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: dev-unsubscribe@synapse.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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: dev-unsubscribe@synapse.apache.org
>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Paul Fremantle
>>>> Co-Founder and CTO, WSO2
>>>> Apache Synapse PMC Chair
>>>> OASIS WS-RX TC Co-chair
>>>>
>>>> blog: http://pzf.fremantle.org
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>



-- 
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org


Mime
View raw message