camel-jms long receiveTimeout preventing shutdown with Oracle AQ
I would like Apache Camel to perform a graceful shutdown within the default 45
seconds. After 45 seconds I would like the the shutdown to be forced.
I normally expect the default 45 second timeout to work, but unfortunately it
does not seem to work when using a JMS component with a long receiveTimeout on
Oracle AQ.
Context file snippet:
Stop Java Code:
private org.apache.camel.spring.Main main;
@Override
public String call() throws Exception {
try {
LOG.info("Received stop command so stopping the server.");
stopApplication();
} catch (Exception e) {
throw new AnException("Error occurred while executing the STOP
command", e);
}
return "DONE";
}
public void stopApplication() {
try {
main.stop();
} catch (Exception e) {
System.out.println("Error stopping camel");
} finally {
System.exit(0);
}
}
@Override
public String execute(CommandInput commandInput) {
// All tasks before graceful shut down goes here..
ExecutorService executor = Executors.newSingleThreadExecutor();
FutureTask ft= new FutureTask(this);
executor.execute(ft);
LOG.info(" Executed stop command asynchronously for JVM {}",
commandInput.getProcessName());
return "STOP";
}
Now if I set my Oracle AQ routes with a short receiveTimeout like this:
aqjms://AQSCHEMA.SOME_AQ?concurrentConsumers=30
jms://SOME_IBM_MQ?concurrentConsumers=20&receiveTimeout=360
...
I get a quick camel shutdown.
Tue May 11 10:15:37 EDT 2021INFOExecuted stop command asynchronoulsy
for JVM SOMETHING ClassWrapper{className='some.class'}Camel (camelContext)
thread #6 - JmsConsumer[AN_IBM_MQ_TOPIC]
Tue May 11 10:15:37 EDT 2021INFOReceived stop command so stopping the
server. ClassWrapper{className='some.class'}pool-10638-thread-1
Tue May 11 10:15:37 EDT 2021INFOCamelContext: camelContext has been
shutdown, triggering shutdown of the JVM.
ClassWrapper{className='org.apache.camel.main.MainLifecycleStrategy'}
pool-10638-thread-1
Tue May 11 10:15:37 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
shutting down
ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
pool-10638-thread-1
Tue May 11 10:15:37 EDT 2021INFOStarting to graceful shutdown 120
routes (timeout 45 seconds)
ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
pool-10638-thread-1
Tue May 11 10:15:37 EDT 2021INFORoute: first_route shutdown complete,
was consuming from: somewhere
ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
Camel (camelContext) thread #3 - ShutdownTask
...
119 more routes shutdown
...
Tue May 11 10:15:38 EDT 2021INFOGraceful shutdown of 120 routes
completed in 1s337ms
ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
pool-10638-thread-1
Tue May 11 10:15:38 EDT 2021INFOApache Camel 3.7.2 (camelContext)
uptime 1d7h9m4s
ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
pool-10638-thread-1
Tue May 11 10:15:38 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
shutdown in 1s539ms
ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
pool-10638-thread-1
Tue May 11 10:15:38 EDT 2021INFOCamelContext: camelContext has been
shutdown, triggering shutdown of the JVM.
ClassWrapper{className='org.apache.camel.main.MainLifecycleStrategy'}
pool-10638-thread-1
Tue May 11 10:15:38 EDT 2021INFOReceived hangup signal, stopping the
main instance.
ClassWrapper{className='org.apache.camel.main.DefaultMainShutdownStrategy'}
Camel Thread #131 - CamelHangupInterceptor
Now if I set my Oracle AQ route to have a long receiveTimeout like this:
aqjms://AQSCHEMA.SOME_AQ?concurrentConsumers=30&receiveTimeout=360
jms://SOME_IBM_MQ?concurrentConsumers=20&receiveTimeout=360
...
I get a slow camel shutdown.
Mon May 10 11:38:38 EDT 2021INFOReceived stop command so stopping the
server. ClassWrapper{className='some.class'}pool-183-thread-1
Mon May 10 11:38:38 EDT 2021INFOCamelContext: camelContext has been
shutdown, triggering shutdown of the JVM.
ClassWrapper{className='org.apache.camel.main.MainLifecycleStrategy'}
pool-183-thread-1
Mon May 10 11:38:38 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
shutting down
ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
pool-183-thread-1
Mon May 10 11:38:38 EDT 2021INFOStarting to graceful shutdown 119
routes (timeout 45 seconds)
ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
pool-183-thread-1
Mon May 10 11:38:38 EDT 2021INFORoute: first_route shutdown complete,
was consuming from: somewhere
ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
Camel (camelContext) thread #3 - ShutdownTask
...
a cou
Re: camel-jms long receiveTimeout preventing shutdown with Oracle AQ
Hi
Do NOT use such a long receive timeout, that is not its purpose.
The timeout should be a reasonable value that allows camel-jms (eg
spring jms) to react on shutdown or stopping, or reducing concurrent
consumers if there are no more pending messages.
On Thu, Oct 7, 2021 at 3:05 PM Mattern, Alex
wrote:
>
> I would like Apache Camel to perform a graceful shutdown within the default
> 45 seconds. After 45 seconds I would like the the shutdown to be forced.
>
> I normally expect the default 45 second timeout to work, but unfortunately it
> does not seem to work when using a JMS component with a long receiveTimeout
> on Oracle AQ.
>
> Context file snippet:
>
>
>
>
>
>
>
> Stop Java Code:
>
> private org.apache.camel.spring.Main main;
>
> @Override
> public String call() throws Exception {
> try {
> LOG.info("Received stop command so stopping the server.");
> stopApplication();
> } catch (Exception e) {
> throw new AnException("Error occurred while executing the STOP
> command", e);
> }
> return "DONE";
> }
>
> public void stopApplication() {
> try {
> main.stop();
> } catch (Exception e) {
> System.out.println("Error stopping camel");
> } finally {
> System.exit(0);
> }
> }
>
> @Override
> public String execute(CommandInput commandInput) {
> // All tasks before graceful shut down goes here..
> ExecutorService executor = Executors.newSingleThreadExecutor();
> FutureTask ft= new FutureTask(this);
> executor.execute(ft);
> LOG.info(" Executed stop command asynchronously for JVM {}",
> commandInput.getProcessName());
> return "STOP";
> }
>
> Now if I set my Oracle AQ routes with a short receiveTimeout like this:
>
> aqjms://AQSCHEMA.SOME_AQ?concurrentConsumers=30
> jms://SOME_IBM_MQ?concurrentConsumers=20&receiveTimeout=360
> ...
>
> I get a quick camel shutdown.
>
> Tue May 11 10:15:37 EDT 2021INFOExecuted stop command asynchronoulsy
> for JVM SOMETHING ClassWrapper{className='some.class'}Camel
> (camelContext) thread #6 - JmsConsumer[AN_IBM_MQ_TOPIC]
> Tue May 11 10:15:37 EDT 2021INFOReceived stop command so stopping the
> server. ClassWrapper{className='some.class'}pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFOCamelContext: camelContext has been
> shutdown, triggering shutdown of the JVM.
> ClassWrapper{className='org.apache.camel.main.MainLifecycleStrategy'}
> pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
> shutting down
> ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
> pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFOStarting to graceful shutdown 120
> routes (timeout 45 seconds)
> ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
> pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFORoute: first_route shutdown complete,
> was consuming from: somewhere
> ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
> Camel (camelContext) thread #3 - ShutdownTask
> ...
> 119 more routes shutdown
> ...
> Tue May 11 10:15:38 EDT 2021INFOGraceful shutdown of 120 routes
> completed in 1s337ms
> ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
> pool-10638-thread-1
> Tue May 11 10:15:38 EDT 2021INFOApache Camel 3.7.2 (camelContext)
> uptime 1d7h9m4s
> ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
> pool-10638-thread-1
> Tue May 11 10:15:38 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
> shutdown in 1s539ms
> ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
> pool-10638-thread-1
> Tue May 11 10:15:38 EDT 2021INFOCamelContext: camelContext has been
> shutdown, triggering shutdown of the JVM.
> ClassWrapper{className='org.apache.camel.main.MainLifecycleStrategy'}
> pool-10638-thread-1
> Tue May 11 10:15:38 EDT 2021INFOReceived hangup signal, stopping the
> main instance.
> ClassWrapper{className='org.apache.camel.main.DefaultMainShutdownStrategy'}
> Camel Thread #131 - CamelHangupInterceptor
>
> Now if I set my Oracle AQ route to have a long receiveTimeout like this:
>
> aqjms://AQSCHEMA.SOME_AQ?concurrentConsumers=30&receiveTimeout=360
> jms://SOME_IBM_MQ?concurrentConsumers=20&receiveTimeout=360
> ...
>
> I get a slow camel shutdown.
>
> Mon May 10 11:38:38 EDT 2021INFOReceived stop command so stopping the
> server. ClassWrapper{className='some.class'}pool-183-thread-1
> Mon May 10 11:38:38 EDT 2021INFOCamelContext: camelContext has been
> shutdown, triggering shutdown of the JVM.
> ClassWrapper{className='org.apache.camel.main.MainLifecycleStrategy'}
> pool-183-thread-1
> Mon May 10 11:38:38 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
> shutting down
> ClassWra
RE: camel-jms long receiveTimeout preventing shutdown with Oracle AQ
Claus Isben,
The reason for wanting a long receive timeout is to prevent the queue server
from having high CPU usage.
Before using this long receiveTimeout setting we experienced very high CPU
usage on our IBM MQ servers. After using a long receiveTimeout setting with IBM
MQ JMS we greatly reduced the server CPU usage with no problems shutting down
the camel application. Interestingly, IBM MQ java libraries supply an option
for an unlimited receiveTimeout, but this is not available in camel so we went
with a one hour setting instead.
Now we are also using Oracle AQ server for JMS. The receiveTimeout setting
seems to create side-effect of long shutdown times with Oracle AQ. What are
some recommended ways to reduced CPU usage on the queue server? I believe that
jms consumer dynamic scaling is available using transactions only with ActiveMQ
and no other queue managers.
--
Alex Mattern
-Original Message-
From: Claus Ibsen
Sent: Thursday, October 7, 2021 10:24 AM
To: users@camel.apache.org
Subject: [EXTERNAL SENDER:] Re: camel-jms long receiveTimeout preventing
shutdown with Oracle AQ
Hi
Do NOT use such a long receive timeout, that is not its purpose.
The timeout should be a reasonable value that allows camel-jms (eg spring jms)
to react on shutdown or stopping, or reducing concurrent consumers if there are
no more pending messages.
On Thu, Oct 7, 2021 at 3:05 PM Mattern, Alex
wrote:
>
> I would like Apache Camel to perform a graceful shutdown within the default
> 45 seconds. After 45 seconds I would like the the shutdown to be forced.
>
> I normally expect the default 45 second timeout to work, but unfortunately it
> does not seem to work when using a JMS component with a long receiveTimeout
> on Oracle AQ.
>
> Context file snippet:
>
>
>
>
>
>
>
> Stop Java Code:
>
> private org.apache.camel.spring.Main main;
>
> @Override
> public String call() throws Exception {
> try {
> LOG.info("Received stop command so stopping the server.");
> stopApplication();
> } catch (Exception e) {
> throw new AnException("Error occurred while executing the STOP
> command", e);
> }
> return "DONE";
> }
>
> public void stopApplication() {
> try {
> main.stop();
> } catch (Exception e) {
> System.out.println("Error stopping camel");
> } finally {
> System.exit(0);
> }
> }
>
> @Override
> public String execute(CommandInput commandInput) {
> // All tasks before graceful shut down goes here..
> ExecutorService executor = Executors.newSingleThreadExecutor();
> FutureTask ft= new FutureTask(this);
> executor.execute(ft);
> LOG.info(" Executed stop command asynchronously for JVM {}",
> commandInput.getProcessName());
> return "STOP";
> }
>
> Now if I set my Oracle AQ routes with a short receiveTimeout like this:
>
> aqjms://AQSCHEMA.SOME_AQ?concurrentConsumers=30
> jms://SOME_IBM_MQ?concurrentConsumers=20&receiveTimeout=360
> ...
>
> I get a quick camel shutdown.
>
> Tue May 11 10:15:37 EDT 2021INFOExecuted stop command asynchronoulsy
> for JVM SOMETHING ClassWrapper{className='some.class'}Camel
> (camelContext) thread #6 - JmsConsumer[AN_IBM_MQ_TOPIC]
> Tue May 11 10:15:37 EDT 2021INFOReceived stop command so stopping the
> server. ClassWrapper{className='some.class'}pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFOCamelContext: camelContext has been
> shutdown, triggering shutdown of the JVM.
> ClassWrapper{className='org.apache.camel.main.MainLifecycleStrategy'}
> pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
> shutting down
> ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
> pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFOStarting to graceful shutdown 120
> routes (timeout 45 seconds)
> ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
> pool-10638-thread-1
> Tue May 11 10:15:37 EDT 2021INFORoute: first_route shutdown complete,
> was consuming from: somewhere
> ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
> Camel (camelContext) thread #3 - ShutdownTask
> ...
> 119 more routes shutdown
> ...
> Tue May 11 10:15:38 EDT 2021INFOGraceful shutdown of 120 routes
> completed in 1s337ms
> ClassWrapper{className='org.apache.camel.impl.engine.DefaultShutdownStrategy'}
> pool-10638-thread-1
> Tue May 11 10:15:38 EDT 2021INFOApache Camel 3.7.2 (camelContext)
> uptime 1d7h9m4s
> ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
> pool-10638-thread-1
> Tue May 11 10:15:38 EDT 2021INFOApache Camel 3.7.2 (camelContext) is
> shutdown in 1s539ms
> ClassWrapper{className='org.apache.camel.impl.engine.AbstractCamelContext'}
> pool-10638-thread-1
> Tue May 11 10:15:38 EDT 2021INFOCamelContext: cam
ToDynamic (toD) problem
Hi,
recently we stumbled across a problem using camel’s “toD” (To-Dynamic)
processor in combination with file and https endpoints.
Sometimes the component-part of the uri seems to get doubled (e.g.
file://file://) which leads to writing the files to the wrong directory (below
file:/). We experienced the same issue with toD in combination with https which
led to https://https:// and therefore to UnknownHostExceptions.
We think this has to do with the optimization (allowOptimizedComponents) that
is done by Camel.
As workaround we switched from “toD” to “to” and using the component-specific
exchange headers to implement the same behaviour as with “toD”. We know that
“toD” optimization can also be disabled, but we think that there is a bug
(maybe somewhere in the SendDynamicAware classes for file and http component)
and have a bad feeling right now using it.
Unfortunately, the issue (especially for file) was not really reproducible and
it only happened in one out of three instances of the running service.
Here is some output of the FileProducer when the problem happened (you can see
the wrongly prepended file:/ on the written file):
{"service":"sampleService","timestamp":"2021-10-05T11:42:45.998+02:00","logger":"org.apache.camel.component.file.GenericFileProducer","level":"DEBUG","thread":"Camel
(sampleService) thread #13 - JmsConsumer[foo.bar]","msg":"Wrote
[file:/tmp/xyz/foo.xml] to
[file://file:///tmp/xyz?fileExist=Fail&fileName=%24%7BexchangeProperty.fileLocation.fileName%7D]"}
We found a JIRA-Ticket which seems to be related to the problem
(https://issues.apache.org/jira/browse/CAMEL-16216) for http-component.
With this simple route you can see that toD optimization seems to wrongly
extract the “host” part and doubles the http component-part when doing
optimization:
from(timer("foo").repeatCount(1).delay(1000)).id("sample")
.setHeader("timeout", constant(1000))
.toD("http:test.dyn?socketTimeout=${header.timeout}");
[mel-1) thread #0 - timer://foo] SendDynamicProcessor DEBUG
Optimising toD via SendDynamicAware component: http to use static uri:
http:http:test.dyn
We used Camel version 3.11.1 in combination with spring-boot 2.5.3.
Has someone experienced similar issues and could some of the camel developers
look into this potential bug?
Thanks,
Nico
dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie
hier.
smime.p7s
Description: S/MIME cryptographic signature
CMIS server
Hello, is it possible with the camel-cmis component to create a CMIS server ? Does anybody has a working example ? Thanks in advance Andrea
