Hans Bausewein wrote:
>
>
> If the consumers store their result in a database (or some other
> transactional application), use XA transactions (2-phase commit). If
> storage fails, the message should go back to the queue where it came from
> (both transactions rolled back) and the other consume
AD-16 wrote:
>
> Hello,
> I am relatively new to activemq and I am trying to find the optimal setup
> for a failover cluster of brokers. What i have is the following
>
> 2 physical servers each running a broker
> 2 physical servers each running a consumer
> 1 Java application implementing
Hello,
I am relatively new to activemq and I am trying to find the optimal setup
for a failover cluster of brokers. What i have is the following
2 physical servers each running a broker
2 physical servers each running a consumer
1 Java application implementing JMS API producer which will like
Since I have had no luck in determining the cause of the exception, I am
trying to at least handle it gracefully. What I am considering is applying
the following patch to the InactivityMonitor in order to trigger a fail over
on the transport...
try
{
Digging through org.apache.activemq.transport.InactivityMonitor I can't
really see why this would occur and thus don't know how to prevent it. It
looks like the WRITE_CHECK_TIMER was canceled somehow, and the
CHECKER_COUNTER != 0... but why or how this occurred I do not know.
Is there any help ou
James Strachan ha scritto:
2008/7/22 DominicTulley <[EMAIL PROTECTED]>:
When the broker is running on port 61616 things work fine but if I change the
broker to use 61613 (for instance) then camel isn't able to connect. I
suppose there is some property I can set inside camelcontext to tell it
2008/7/22 DominicTulley <[EMAIL PROTECTED]>:
>
> When the broker is running on port 61616 things work fine but if I change the
> broker to use 61613 (for instance) then camel isn't able to connect. I
> suppose there is some property I can set inside camelcontext to tell it the
> port to use, but I
When the broker is running on port 61616 things work fine but if I change the
broker to use 61613 (for instance) then camel isn't able to connect. I
suppose there is some property I can set inside camelcontext to tell it the
port to use, but I haven't been able to discover what that is...
My XML
Hi,
maybe you can try ExceptionListener or TransportListener to handle these
async exceptions?
Regards
--
Dejan Bosanac
www.scriptinginjava.net
On Mon, Jul 21, 2008 at 9:24 PM, rbrown3 <[EMAIL PROTECTED]> wrote:
>
> Greetings:
>
> I am running an application that has an embedded ActiveMQ bro
Thx, i'll check it out
Dejan Bosanac ha scritto:
Hi,
it's possible. Take a look at the receipt header in the Stomp protocol which
is used for this purpose
http://stomp.codehaus.org/Protocol#Protocol-Receipt
But, it's up to the client whether it will be supported. PHP client supports
it like t
Hi,
it's possible. Take a look at the receipt header in the Stomp protocol which
is used for this purpose
http://stomp.codehaus.org/Protocol#Protocol-Receipt
But, it's up to the client whether it will be supported. PHP client supports
it like this
http://stomp.codehaus.org/PHP+Synchronous+vs.+A
thanks, that made it.
I checked the Net::Stomp library for Perl but i didn't find a way to set
the producer
to use sync sends, only to set sync consumer.
do you know if it is possible to achieve the same result with a Stomp
client?
Joe Fernandez ha scritto:
Try setting the connection factory
Although it is not the same product and not the same scale (hopefully it will
get to that :-)). Think of a system like youtube where data is big and both
the data and traffic keeps on growing. As opposed to youtube (I guess) in
this case most of the messages are big 1-10M (can be even more but I e
13 matches
Mail list logo
