Oh, you are using camel-cxf.
Can you just check the log to see if sync invocation can be time out?
If you setup the timeout, I don’t think camel-cxf producer can block thread
forever.
BTW, you can use some thread monitor tool to check what blocks the thread.
If you want to implement a timeout t
Hi Willem
Thanks for your reply,
already we are configuring the time out changes in camel-cxf.xml as below
before making the synch call(using worked thread).
http://xml.comcast.com/commercialcustomer/services}CommercialCustomerServicePort.http-conduit";>
But still we
Here are the answers for you questions.
Q1. The default camel thread pool is using CachedThreadPool which means it
doesn’t set up the thread size.
Q2 If the calling thread is blocked, it still there, thread pool doesn’t reuse
it.
That could explain why you got the OOM error.
If you setup the
Corrected typo error
Hi Willem
We are getting the OOM memory error in our production environment due to the
lot of stuck threads.
while analyzed the code we found that one of the camel route which is using
the mulitcast is the reason for the stuck thread.This is intermittent issue
.
Please find
I think I found the issue, shareUnitOfWork should create the a new
UnitOfWorkProcessor per processing instead of using the last one, as the parent
UnitOfWork is different next time. When you using the shareUnitOfWork, the
error handler should just get one call.
I will commit the fix after runnin
Hi,
I can reproduce this kind of error in the trunk by adding a simple unit test
as you said.
If I remove the shareUnitOfWork setting, the error handler can get expect
numbers messages.
So I just fill a JIRA CAMEL-6005[1] for it.
[1]https://issues.apache.org/jira/browse/CAMEL-6005
Willem
--
