Thanks Tim, that is exactly what I needed.
Best regards,
Frank
On 17.08.2011 17:04, Timothy Bish wrote:
On Wed, 2011-08-17 at 09:43 +0200, Frank Gynnild wrote:
Thanks a lot for your information, I really appreciate it.
I'll start retesting using these configuration changes as it seems like
NMS also supports
these properties. I'll let you all know when the results are ready.
Does anyone know of a exhaustive list of all configuration parameters
that can be tweaked on the
NMS client side (using the OpenWire protocol) and on the broker side?
Does the client side
settings always override those set on the broker side, in other words;
what determines the
effective settings?
Best regards,
Frank
The NMS Client URI options are listed here:
https://activemq.apache.org/nms/activemq-uri-configuration.html
Options set on the client side will override the broker side.
Regards
Tim.
On 16.08.2011 23:58, Martin C. wrote:
Hi,
first, you can use JMX on the broker to disconnect the connection of
the hanging consumer. But this is a very rude work-around, of course.
We had a similar issue connecting with Java-based consumers. We seem
to have found a work-around by disabling caching and tight encoding on
the OpenWire wire-format by using
"wireFormat.cacheEnabled=false&wireFormat.tightEncodingEnabled=false".
We haven't had no issue in production for almost 10 days now, whereas
we had one once every day before the settings change.
I don't know if NMS also supports those options, if yes, you might
want to give them a try.
Best regards,
Martin
On Tue, Aug 16, 2011 at 11:17 PM, Frank Gynnild<fr...@gynnild.com> wrote:
Hi everyone
The problem:
I have a random issue using ActiveMQ 5.5 and the latest NMS library from
.NET.
A unit test creates and sends 1 000 000 messages of random size.
Simultaneously
a consumer tries to pick up these messages as fast as it can. Most of the
times
all messages are received as expected, but every now and then this situation
occurs:
1) After x number of messages, the consumer stops picking up messages.
2) The producer continues to send messages until all messages are sent.
I've also tried it from different machines, and the problem occurs randomly.
The symptoms:
- When this occurs, browsing messages on the queue in the ActiveMQ console,
shows no messages on the queue (the number of pending messages are there,
but the list of messages can't be viewed).
- There's no error or trace in the ActiveMQ log when this happens.
Workaround:
- The only way I've found to recover from this situation is to restart the
ActiveMQ.
- In the ActiveMQ log, I always see these lines:
2011-08-16 22:54:49,848 | INFO | Recovering from the journal ... |
org.apache.activemq.store.kahadb.MessageDatabase | main
2011-08-16 22:54:49,849 | INFO | Recovery replayed 1 operations from the
journal in 0.109 seconds. | org.apache.activemq.store.kahadb.MessageDatabase
| main
- The unit test pick up from where it left and completes (I'm using the fail
over protocol).
Is this a known bug? Is there a work around that doesn't involve restarting
the ActiveMQ service?
Best regards,
Frank
