Clebert Suconic wrote:
- Importing, there shouldn't be a need to load the target journal. We could just query the destination and create the queue when needed.
Clebert, this is done now.
The handleMessage() now queries the queue name which the message should be bound to using session.queueQuery().
If the queue does not exist, create it. Further add a mapping for old/new queue ids.
The QueueQuery object didn't carry the queue ID. I've added that (and the name as well) to make the mapping work. The SessionQueueQueryResponseMessage was affected as well.
The UnitTest passes (50-99 asserts after the import) except an error in tearDown():
junit.framework.AssertionFailedError: invm registry still had acceptors registered
I'll investigate that tomorrow.
Torben Jaeger wrote:
SessionQueueQueryResponseMessage was affected as well.
I think with the modification of this object I've introduced some compatibility issues.
I did a test run at ... (u know the customer). The export went fine but I've got problems with the import (ArrayIndexOutOfBounds) because of this object.
An older version of SQQRM doesn't know anything about the queue ID which I need in order to map old and new queues. So it's not encoded in the response (old SessionQueueQueryResponseMessage::encodeRest()) which I decode with the assumption that the ID is included (new SessionQueueQueryResponseMessage::decodeRest()).
As this is also used if a consumer is created (ServerSessionPacketHandler::handlePacket(), PacketImpl::SESS_CREATECONSUMER) I am not sure about the compatibility of different versions.
Maybe the creation of a consumer will fail then.
We have to be aware of this ...