On Thu, Nov 14, 2013 at 1:50 AM, Scott England-Sullivan
wrote:
> Hi Harald,
>
> First off, I would be hesitant to have multiple SJMS projects. We want to
> take everyones good work to build a better product overall while keeping
> Camel as simple and easy to use as possible.
>
> WRT your question
Hi Harald,
First off, I would be hesitant to have multiple SJMS projects. We want to
take everyones good work to build a better product overall while keeping
Camel as simple and easy to use as possible.
WRT your question, SJMS was built to live in any environment. It does have
its own built in
As a proof of concept, I created a new component camel-sjmsee as a
simplified version of camel-sjms:
https://github.com/hwellmann/camel/tree/sjmsee/components/camel-sjmsee
Given that a Java EE container provides connection pools anyway, this
component does not pool any connections, producers or In
Ok, I'll watch that issue.
Broadening the scope of the discussion a bit, is SJMS designed for Java
SE, Java EE or both?
In a Java EE 6/7 server, you get managed connections from a JCA resource
adapter, pooling and reconnection is provided by the container, so
there's no need to add reconnect
Yes, exactly. JIRA: https://issues.apache.org/jira/browse/CAMEL-6950.
Regards,
*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter:
Hi
It does sounds like camel-sjms lacks the re-connect functionality that
camel-jms has by the spring's default message listener container.
On Fri, Nov 8, 2013 at 2:22 PM, Harald Wellmann wrote:
> Here's a slightly different scenario demonstrating the issue with SJMS,
> this time not involving
Here's a slightly different scenario demonstrating the issue with SJMS,
this time not involving stale temp queues:
1) Start ActiveMQ Broker
2) Start JBoss with Camel/SJMS consumer application
3) Run one-shot producer application (i.e. simple program which sends one
message and then exits).
4) Ever
The real problem is not that the temp queue is gone, the fatal thing is
that SJMS stops working after one attempt to send to a missing queue.
I've tried to debug the situation, and it seems that SJMS creates sessions
in advance from connections obtained from JBoss, but JBoss closes each
connection
I don't think the situation can be avoided – if anything, it can be
contained via AMQ broker configuration.
Take a look at [1]. Should be a similar situation.
[1]
http://stackoverflow.com/questions/6432672/activemq-how-to-handle-broker-failovers-while-using-temporary-queues
Regards,
*Raúl Kripa
That might help in some cases, but I don't see how it solves the problem,
when the producer dies before the message TTL is over.
Regards,
Harald
2013/11/8 Raul Kripalani
> If these are request-reply interactions, producers should set a Time To
> Live when sending a message to the queue. The br
If these are request-reply interactions, producers should set a Time To
Live when sending a message to the queue. The broker will then expire stale
messages automatically and they won't be delivered to the consumer, thus
reducing the risk of the consumer sending out unexpected replies like this
one
I'm using Camel 2.12.1 with SJMS on JBoss AS 7.2.0 with the ActiveMQ 5.7.0
resource adapter and an external broker.
My application has a route consuming request-reply messages from an
ActiveMQ queue via SJMS. The connection factory is obtained from JBoss via
@Resource injection.
When I stop my ap
12 matches
Mail list logo
