Per spec, the way CXF is working is OK.
Basically, on the server side, the server should return the 200/201 as soon as
the message is received (and we can tell it's a oneway). It should not wait
until the message has been fully processed and dispatched and such. For SOME
transports and in some servlet containers, the only way to do that is to
pretty much return from that thread immediately. Thus, the runnable on the
work queue.
Per spec, the client call should then return prior to the request being
dispatched into the method. It could then send another request prior to the
first one-way really being complete, or even dispatched.
Even if we could dispatch on the current thread and not use the workqueue,
there is no guarantee of ordering when using the one-ways. For example, with
JMS, as soon as the message is posted to the queue, the client returns and it
could send another message. In a multi-threaded server, both messages could
arrive at the server at the same time. If the first message takes longer to
parse/process (like maybe it's larger or has extra security requirements or
similar), the second could easily be dispatched to the implementation prior to
the first one.
Dan
On Thursday 25 November 2010 11:11:39 am Hervé BARRAULT wrote:
> Hi,
> i'm using CXF 2.2.11 and a monothreaded http client which loops to send
> request sequentially and i have found a particular behavior, the order of
> incoming messages is not always kept.
>
> It seems happening when the AutomaticWorkQueue is full.
>
> I have looked to the code and i have found in the
> OneWayProcessorInterceptor
>
>
> public void handleMessage(Message message) throws Fault {
> ...
> *try {
>
> message.getExchange().get(Bus.class).getExtension(WorkQueueManager.class)
> .getAutomaticWorkQueue().execute(new Runnable() {
> public void run() {
> chain.resume();
> }
> });
> } catch (RejectedExecutionException e) {
> //the executor queue is full, so run the task in the
> caller thread
> chain.resume();
> }*
> ...
> }
>
> But in the case where you are running the task in the caller thread it is
> handling the newest message not the oldest so the order is not preserved.
>
> in the called method, i print the thread and the message number (to easily
> see the behavior i had a sleep of one second.
>
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 1 PROCESSED
> thread : thread[5169...@qtp-5024475-0,5,main]
> MESSAGE 12 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 2 PROCESSED
> thread : thread[5169...@qtp-5024475-0,5,main]
> MESSAGE 14 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 3 PROCESSED
> thread : thread[5169...@qtp-5024475-0,5,main]
> MESSAGE 16 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 4 PROCESSED
> thread : thread[5169...@qtp-5024475-0,5,main]
> MESSAGE 18 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue] <= The 19th
> message has been sent and i stop sending
> MESSAGE 5 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 6 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 7 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 8 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 9 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 10 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 11 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 13 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 15 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 17 PROCESSED
> thread : Thread[default-workqueue-1,5,default-workqueue]
> MESSAGE 19 PROCESSED
>
>
> I would know why the implementation does not keep the message order ?
>
> Thanks for answers.
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
