Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@synapse.apache.org
Received-SPF: pass (athena.apache.org: domain of pzfreo@gmail.com designates
 209.85.134.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=m9k9FzgnxkDIENT41sit1n2I0M+xOR6ssZrJBhH++adtjjGh61haSN6LaZPusMFQ8A
         uiz/ZfMBD+NrEYnrZy9Edj6zApNMwNTKobLA9GwSg0JBgQlfILa7+wkSGzSz4x7h0oOE
         csI8A6AMyPqq8zY9OyXhKGwaKDwUapJV3rWo4=
Message-ID: <88f5d710811100531p19f17f58m9a0fe5fc0e1fe932@mail.gmail.com>
Date: Mon, 10 Nov 2008 13:31:42 +0000
From: "Paul Fremantle" <pzfreo@gmail.com>
To: dev@synapse.apache.org
Subject: Re: [SUGGESTION] New Sample
In-Reply-To: <b67458760811100516v4be878ffnab4f87f9183a8947@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <490EA902.6040808@wso2.com>
	 <b67458760811031243m1b5d7a23ve80c90c897445403@mail.gmail.com>
	 <4913A5F5.8040401@opensource.lk>
	 <b67458760811091350t6f8af25cr11a389f3a3aaa717@mail.gmail.com>
	 <88f5d710811100341m3aeaaa25o47cde4d961a8ba25@mail.gmail.com>
	 <b67458760811100516v4be878ffnab4f87f9183a8947@mail.gmail.com>

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