Hmm, it sounds odd that there's an error indicating the value needs to be
set. The TCP transport sets defaults if they are not provided.
Can you provide the text of that error message?
The URL looks right. However, there is some magic to the linkage of the
wireformat that makes it hard to be 10
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
We are running into an issue with ActiveMQ JMS to JMS Bridge.
On Server A we have a stand alone instance of ActiveMQ with 4 queues:
queue_1_inbound
queue_2_inbound
queue_3_inbound
queue_outbound
On Server B we have 3 embedded ActiveMQ instances, each in their own JVM.
JVM 1 will have an inb
See http://activemq.2283324.n4.nabble.com/PPA-for-Debs-td4683151.html
On 29 July 2014 00:51, Kevin Burton wrote:
> I'm thinking about creating debian packages for 5.10 …
>
> doesn't seem like they exist for 5.10 from debian directly.
>
> … and it seems like activemq deserves somewhat fresh pac
13 matches
Mail list logo
