I've started playing with CXF + Camel + JMS, and have set up a sample client
and service that can put and get messages from a JMS Queue.
I've started going deeper to understand the transaction and retry logic since
one of the use cases I have is to use either the JMS or Camel retry logic to
rep
aware of and handle the exception,
even if CXF is generating an out fault message, for things like transactions,
retry and dead message queues.
-Original Message-
From: Willem Jiang [mailto:willem.ji...@gmail.com]
Sent: Wednesday, June 08, 2011 6:33 PM
To: us...@cxf.apache.org
Cc: Sven
Actually you won't be able to catch the exception, since this is caught and
handled in Spring-JMS AbstractPollingMessageListenerContainer. It's not retry,
so much as just constantly polling the destination regardless of success or
failure. You may be able to install an ErrorHandler, although I
--Original Message-----
From: Sven Zethelius
Sent: Monday, June 27, 2011 8:13 AM
To: users@camel.apache.org
Subject: RE: Unable to catch exception from Camel.
Actually you won't be able to catch the exception, since this is caught and
handled in Spring-JMS AbstractPollingMessageListenerConta
or you can download it from maven repositories directly if you aren't using
maven:
http://search.maven.org
From: Christian Schneider [ch...@die-schneider.net]
Sent: Friday, September 30, 2011 4:49 AM
To: users@camel.apache.org
Subject: Re: 2.8.1 source?
Synchronized doesn't save you from ConcurrentModificationException. CME
happens when you are iterating and the list changes from when the list was
first created, even from the same thread. For example if someone does
myList.add while you are in the for loop, it would trigger the CME.
Given
I'm guessing what you are seeing isn't actually the 15ms "delay" but instead
the windows time granularity, which is around 15-16 ms.
http://code.google.com/p/javasimon/wiki/SystemTimersGranularity
From: ebinsingh [ebenezer.si...@verizonwireless.com]
Sent:
I suspect you aren't caching the connection/sessions. Try wrapping the
connectionfactory with a
org.springframework.jms.connection.SingleConnectionFactory or
org.springframework.jms.connection.CachingConnectionFactory. In your direct
case, you have a persisted connections, and most likely a s
Camel Producer uses a Spring-JMS JmsTemplate. The JmsTemplate doesn't keep a
reference to JMS Connection or Session between calls to execute. It relies on
the ConnectionFactory to manage that, hence the SingleConnectionFactory and
CachingConnectionFactory.
-Original Message-
From: Rad
No idea. Next steps are probably to turn on tracing on the Camel Context so
that it logs a record of every message sent. Then you can use that to
correlate and see if Camel thinks the JMS provider accepted the message, then
start looking at possibly the messages being lost by the JMS implement
We ran into similar issues (DBCP as well). Our solution was to create a bundle
that embedded (Bundle-Classpath) JTDS and DBCP into a single bundle so that
they shared classpath. From there you can export the necessary packages so any
other bundle may create the DataSource/Connection instances
11 matches
Mail list logo
