fixing compatibility issues + testsuite on compatibility#1713
Conversation
9bb541f to
5a3f481
Compare
|
@clebertsuconic instead of this mass interface changes to pass around CoreRemotingConnection, why not add ability to simply set the packet (either using default method and field java 8, or could be done in PacketImpl) with the channel (connection) version as it arrives before it gets decoded and passed through channel handlers, and then the information will be with the packet, where it needs special handling, would avoid this larger interface change. |
|
@michaelandrepearce I thought it would be more complete that way.. would make sure we would have the connection during the encoding for anything else we needed. |
5a3f481 to
34e9570
Compare
|
@mtaylor I added hornetq to the picture here now. and it looks good. next step is to add 1.4 as server.. and I see a few issues now. |
34e9570 to
099386a
Compare
|
@clebertsuconic @michaelandrepearce We actually already have ClientPacketDecoder and ServerPacketDecoder which are supposed to be used to encapsulate the decoding logic. Why not just implement a new ServerPacketDecoder1_4. This gets set up on connection entry so you have the version info already. We don't use an encoder on the way out, but we could easily add something similar? |
|
@mtaylor the parsing of the Message happens inside the CoreMessage.. trying to avoid copy between the incoming buffer... Move "the hack" to PacketImpl would be a bit complex... But i will minimize the number of changes. |
6f2b340 to
030403f
Compare
|
@mtaylor the "hack" still in message but it's activated through the Packets... I still had to add connection to a lot of places.. as well as making the version-id orthogonal.. This is also fixing 1.4 as server as I added a new change. |
030403f to
1be0903
Compare
|
@michaelandrepearce I tried to simplify as much as I could |
ae65176 to
dc93ed3
Compare
| // } | ||
| if (bindings == null && context.getAddress() != null) { | ||
| AddressSettings settings = server.getAddressSettingsRepository().getMatch(context.getAddress().toString()); | ||
| if (settings.isAutoCreateQueues()) { |
There was a problem hiding this comment.
@mtaylor Please review this.. this is fixing the compatibility between a 1.4 server and a 2.5 (snapshot) client.
| CreateAddressMessage request = new CreateAddressMessage(address, routingTypes, autoCreated, true); | ||
| sessionChannel.sendBlocking(request, PacketImpl.NULL_RESPONSE); | ||
| if (!sessionChannel.getConnection().isVersionBeforeAddressChange()) { | ||
| sessionChannel.sendBlocking(request, PacketImpl.NULL_RESPONSE); |
There was a problem hiding this comment.
@mtaylor this is fixing some compatibilty issues
|
@mtaylor with this last commit, this completes the full mesh. Everything compatible.. at least on these tests I have now.. I'm adding more next week. |
dfe419c to
f5bf9d0
Compare
|
DON'T MERGE THIS... @mtaylor help me review the auto-create stuff on that side... perhaps we only do that for previous versions... Testsuite is broken after this last commit..I can take out some of the auto-create, but we still need the other stuff... lets talk on monday... So... again... DON'T MERGE THIS yet |
80ac192 to
23282db
Compare
https://issues.apache.org/jira/browse/ARTEMIS-1546 - the dependency scan is changed to allow adding an extra repository - adding groovy so we won't require compilation dependencies (just runtime) without needing reflection (thanks Groovy :) ) - Adding hornetq to the mesh of version tests
https://issues.apache.org/jira/browse/ARTEMIS-1546 Recasting the body as 1.x format when there's a 1.x in use at the other size of the wire
23282db to
dbe575a
Compare
No description provided.