Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <49046A38.7020201@die-schneider.net>
Date: Sun, 26 Oct 2008 14:01:44 +0100
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Daniel Kulp <dkulp@apache.org>
CC: dev@cxf.apache.org
Subject: Re: JMS transport sync/async......
References: <200810231014.33705.dkulp@apache.org>
In-Reply-To: <200810231014.33705.dkulp@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dan,

I have looked into ClientImpl and JMSConduit. I think the code you added 
should work.
The JMSConduit.onMessage is called from DefaultMessageListenerContainer 
which uses a spring TaskExecutor. Additionally it can be configured
to use several threads to listen on jms messages. So I think there is no 
need for a workqueue.
Additionally ClientImpl uses another executor.

Btw. is it really necessary to do different things for sync and async? 
Of course the ClientImpl has to support a sync and async mode but I think
the transports could be made completely async. Does the Exchange even 
has to know if it is synchronous?

About your question regarding the wait. I would like to remove the wait 
and also the config option receiveTimeout. If the Client can do this 
then that is the better solution.
There is one thing we have to keep in mind though. The sendExchange 
method adds an entry to the correlationMap. This has to be removed after 
the timeout. Normally this is done after the wait.
I guess there is no easy solution for this problem. Generally I would 
suggest doing the whole correlation already in the client. So we could 
keep this out of the transport code.

Another thing are the Executors and Workqueues. The current spring 
versions already provide this functionality. Do you think it is possible 
to switch to
the spring implementations and remove this code from cxf?

Greetings

Christian


Daniel Kulp schrieb:
> Christian,
>
> When you get some time, can you look at what I've done in the JMS transport to 
> make sure it's all OK and doesn't introduce some massive scalability issue?
>
> Basically, I now call the message observer directly from the 
> onMessage(JMSMessage)  call.   This means its called on the thread that the 
> JMS queue provides instead of from the CXF calling thread.    Right now, if 
> it's a synchronous invoke, I left the "wait()" in place on the main thread, 
> but that's really not needed.    It could return immediately as the 
> ClientImpl will then wait if it's supposed to be synchronous.   I mostly left 
> it there due to the jmsTemplate.getReceiveTimeout() thing.   If we return, 
> the timeout would need to be configured on the client itself,  which might 
> not be a bad thing.   Not really sure.    Maybe the default could be 
> RECEIVE_TIMEOUT_NO_WAIT and only wait on that main thread if it's set 
> otherwise?   I don't really know, not my area of expertise.
>
> I guess my main concern is if it's OK to process the response on the JMS 
> provided thread.   Is that part of a thread pool or similar?   If not, we'll 
> need to throw it on a workqueue.   That's easy enough to do, but I wanted to 
> hear from you first.
>
> Thanks!
>   


-- 

Christian Schneider
---
http://www.liquid-reality.de