I think the solution is simply to create an explicit ConnectionFactory and
set it as the localQueueConnectionFactory on the bridge:
...
...
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-tp4679181p4704980
I think the solution is simply to create an explicit ConnectionFactory and
set it as the localQueueConnectionFactory on the bridge:
...
...
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-tp4679181p4704983.ht
is your problem solved?
i have exact same problem as yours.
if you find the solution could you please share it with me?
Thanks
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-tp4679181p4703904.html
Sent from the ActiveMQ - User mailing list archive at N
I filed https://issues.apache.org/jira/browse/AMQ-5342 with the configuration
of the brokers, consumer, producer and full thread dump.
The two brokers are running in their own JVMs connecting to each other over
tcp open wire. Internally the brokers create vm transports to bridge among
their connec
Hmm, it looks like there are two reentrant locks.
Are there 2 brokers running in the same JVM connecting over a network
connector with the VM transport?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-bridge-reconnection-dispatching-not-working-in-simple-condi
Good catch. Something looks very wrong with this deadlock picture. Both
threads are blocking on this call:
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:66)
Which is this instruction:
writeLock.lock();
Which is this method call:
java.util.concurrent.locks.
Actually it has caused problems with my integration test environments
because is completely unexpected and Spring doesn't now about kill -9, it
only knows about calling the shutdown hooks.
I ran JConsole and immediately detected this deadlock:
Name: ActiveMQ Transport: tcp://localhost/127.0.0.1:6
The issue of "connection takes a long time to shutdown" has been around a
long time. I've seen at least one fix for it recently, but it may still
have other causes.
If you can track down the cause and (even better) provide a patch, it would
be greatly appreciated.
Once reproduced, the next step
I ran the same topology with everything in the same server, both brokers,
producer and multi-threaded consumer. I can reproduce this EVERY SINGLE
TIME.
I tried with 5.9.1 and see exactly the same behavior. I tried with 5.6
(which is the version I run in production) where I know this basic topology
There are 3 scenarios where ActiveMQ behaved as designed:
1. Outbound Bridge disabled. This always worked.
2. With Outbound Bridge enabled, it intermittently worked for specific
embedded brokers and not for others, then it would flip on us. Same configs
an all.
3. With Outbound Bridge enabled, w
It's possible. Although, I didn't see any prefetch=0 use in your configs
(could be I didn't look hard enough since I didn't suspect it). Prefetch=0
uses different code paths for delivery of messages to clients - clients must
poll the server, and the server synchronously returns a message, with
pr
I noticed there is another Topic in the forums that sounds similar to our
issue.
http://activemq.2283324.n4.nabble.com/ActiveMq-consumer-intermittently-hanging-after-reconnect-td4684226.html
Could we be experiencing the same problem. The JMS Bridge basically creates
a Consumer and Producer.
-
Good question, difficult answer:
Once we saw that the issue continued no matter where the Broker Bs resided,
we started looking at the configuration more in depth and leave the Broker
Bs where they were on Server B. We did make some changes to the configs for
all of the Broker B's like setting th
Good troubleshooting. What's different between the working and non-working
setups? Only the network?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-Connection-tp4684129p4684205.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
As far as I know, transactions are not being used. We did not set any
configurations to use transactions even with the Camel Routes.
As far as other scenarios, we have tried the following (Broker A is always a
stand alone instance):
*Same Server*
Broker A and embedded Broker B[1,2,3] are running
For keep-alive packets, I was referring to the inactivity monitor and not TCP
keep-alive packets.
The documentation is correct - the default is not to enable TCP keep-alive
packets on the socket.
I don't think there is any conflict between the two.
One thought is coming to mind here after re-rea
Broker B which creates the Bridges is giving the EOFExceptions. But which
part of Broker B we do not know. We suspect it is the Producer for the
Outbound Bridge. The reason is two fold:
1. Comment out the Outbound Bridge and everything else works as designed.
2. The messages are never pushed fr
If the drop-outs occur while there is heavy traffic flowing over the bridge,
keep-alive packets are not even part of the problem. Keep-alive packets are
only sent when the connection is idle for a period.
EOF Exception means "End-Of-File" on input, not a bad value read. In this
case it means the
This does help, thanks! But doesn't explain why would we get this behavior
while pushing over a large number of messages (example - 500). The
connection is lost and the EOFException is logged. A couple of questions:
1. Does the keepAlive flag need to be on the TransportConnector for ServerA,
or
That helps a lot.
The inactivity timer fires when there is no communication between the
brokers for more than the timeout period (apparently 30 seconds); keep-alive
packets are used to prevent inactivity timeouts. So, the fact that
inactivity timeouts occur means that either the keep-alives are n
It is not easily reproducible via a test case.
More Info:
- The inbound bridge would transfer over messages up to a point. Meaning if
we have 40 messages they would all get transferred, but if we had 500
messages not all would be transferred. However, the Queue's Pending Message
Count on Serve
Hmm, the inactivity timer is closing the connection:
2014-07-25 17:37:52,373 | DEBUG | Transport Connection to: tcp://[IP
ADDRESS]:4507 failed: org.apache.activemq.transport.InactivityIOException:
Channel was inactive for too (>3) long: tcp://[IP ADDRESS]:4507 |
org.apache.activemq.broker.Tran
Drilling down into the code further, the readInt() method calls the read()
method 4 times in TCPBufferedInput.
Unfortunately, I do not have a copy of Server A's log file for this time. I
do have a copy from earlier in the day. Not sure if this will help, but
these messages seemed to come up ar
Is it easily reproducible?
What symptoms have been observed? It sounds like message flow stops across
the bridges, and the EOF exception is mentioned. Anything else?
Turning debugging logging on for Region may help (try setting
org.apache.activemq.broker.region to DEBUG in log4j.properties).
T
Yes, both Brokers are running in 5.10.0.
Not sure if it happens after the problem starts or before. The log message
posted is what we get. So, we are not sure if the EOFException is causing
the Connectors to disconnect. Or if the EOFException is being caused by the
Connectors being disconnected
Here is the code throwing the Exception:
if (!sizePrefixDisabled) {
int size = bytesIn.readInt();
It appears to be right at the beginning of an openwire packet. Very odd if
both sides of the connection are talking openwire, unless the connection is
simply being dropped.
Wha
The configuration is properly using the failover transport, and the logs show
reconnects. So, the TCP transport exception-handling is not the problem.
Does the EOF exception occur every time after the problem starts? The stack
trace suggests a problem at the level of the OpenWire protocol. Perh
That's what it looks like. Both bridges (A to B, and B to A) are defined on
one broker.
Looks good.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-vs-Network-of-Brokers-tp4681063p4681121.html
Sent from the ActiveMQ - User mailing list archive at Nabbl
The JMS bridge is a good solution to use. I disagree with the statement in
the referenced discussion that the demand-forwarding bridge is always more
efficient and a better choice always for ActiveMQ-to-ActiveMQ.
Without getting into too much detail, the JMS bridge is a good choice when
there is
Thanks for the response.
To answer your question: What we want is a non demand forwarding bridge
from Broker A to Broker B for one queue. And a non demand forwarding bridge
from Broker B to Broker A for another queue.
After doing some more fiddling around, I think we got it to work. Here is
how w
Thanks for that link, that is exactly where I found the use of
localUsername and localPassword. I understand the concept of using JAAS
security in a broker and how it controls access to Queue's,Topic's and
Advisories. I guess I need to re word my question.
I have configured what seems to be what i
The JMS bridge connects into the broker like a client.
See the localUsername and localPassword settings.
http://activemq.apache.org/jms-to-jms-bridge.html
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-tp4679181p4679182.html
Sent from the ActiveMQ -
On Wed, 2012-10-31 at 05:35 -0700, d_van_rietschoten wrote:
> Hello,
>
> I have a JMS to JMS bridge. Although it functions well, the throughput is
> low (roughly about 1 message a second).
> I am not very familiar with ActiveMq, but have used Jboss messaging /
> HornetQ. These products provide ba
ok, there is a new announcement in the news section and the download
link now has the latest version in it, that should help clarify the
latest available release. Thanks for the feedback.
On 27 August 2010 22:13, TreyH wrote:
>
> Thanks Gary. I'm a little confused about the status of 5.4. The
Thanks Gary. I'm a little confused about the status of 5.4. The last
update here: http://activemq.apache.org/ shows 5.3.2 as the current version.
5.4.0, however, is showing up on the download page. I'll give 5.4 a try on
our development environment though... thanks.
Gary Tully wrote:
https://issues.apache.org/activemq/browse/AMQ-2455 - is fixed in
5.4.0, try it out.
On 26 August 2010 21:32, TreyH wrote:
>
> About once a day my JMS-to-JMS bridge stops and requires a restart of
> ActiveMQ to get it to resume. I don't get anything bridge related showing
> up in my data/activemq
Of course, missing the important info.
I'm using ActiveMQ 5.3.1, JDK 6, FreeBSD 8
TreyH wrote:
>
> About once a day my JMS-to-JMS bridge stops and requires a restart of
> ActiveMQ to get it to resume. I don't get anything bridge related showing
> up in my data/activemq.log
>
> This is a sin
Thanks for the response. I will check out Camel to see if that makes sense
for my use case. (If that's the "best practice", I think the JMS-to-JMS
Bridge page on the ActiveMQ site should be updated to recommend that.)
In the meantime, I've already invested a lot of time into the ActiveMQ
solutio
I'd be tempted to use Camel instead...
http://activemq.apache.org/camel/enterprise-integration-patterns.html
then under the covers its using Spring and their JMS helper classes etc
http://activemq.apache.org/camel/jms.html
2008/8/22 darickard <[EMAIL PROTECTED]>:
>
> I've been trying to cr
39 matches
Mail list logo
