I think backward compatibility for middleware is pretty important (esp. for different minor releases).
Consider an enterprise where there are several different applications connecting to a central broker, requiring all clients to upgrade their jars on a server upgrade might be a concern for some organizations. Oracle 8 and 9 drivers work with Oracle 8, 9 and 10 servers. Similarly I believe RMI from JDK 1.3 ( and JDK 1.4) is able to talk to RMI from JDK 1.5 although the internals have changed significantly. The client server version checking for incompatibilities should be something that an application may chose to enforce if ,say, the semantics of the business logic or domain have changed which leaves older clients incompatible with newer application releases. On a middleware project that I worked on we had test suites run with older clients/newer servers as well. Sanjiv On 7/5/06, James Strachan <[EMAIL PROTECTED]> wrote:
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/
