Great - glad to hear its all working fine now :) Its sometimes hard ensuring the semantics are preserved from release to release; I'm wondering if the default behaviour of ActiveMQ should be to refuse to connect to a client using another jar version (unless explicitly configured to be lenient).
We've a version number in OpenWire we can increase when we make things incompatible on the wire format; am wondering if we should at least log some kind of warning if (say) a 4.0 client talks to a 4.0.1 broker as there could be some kind of issue arise. It seems a pretty common problem people having a wrong jar on some node in the network causing strangeness On 7/5/06, Dave cawthorn <[EMAIL PROTECTED]> wrote:
BTW this use case is a very inefficient use of JMS... I know, it was just a test case to try and expose the problem that i was having. Thanks for the link though, it came in handy for "Discussions" with one of the other developers here ;-) Which version of ActiveMQ are you using and can we see your Java code? With some embarrassment I have to admit that my problem appears to have been from the fact that my broker was version 4.0.1 but my testing environment (eclipse/junit) was still using the 4.0 jar. This was what probably was causing the client to hang. After rectifying that situation I have managed to run my test for 2 hours and it appears to be stable now. I'm going to run a more comprehensive test using our actual code overnight to see if I've solved the problem i was having. Thanks for your support James! Dave -- View this message in context: http://www.nabble.com/AMQ-4.0.1-Memory-Leak-Hang-tf1889180.html#a5177708 Sent from the ActiveMQ - User forum at Nabble.com.
-- James ------- http://radio.weblogs.com/0112098/
