How can I filter to messageHeader attribute (correlationID) when creating a consumer?

[exe]

How can i filter in the QueueChannel.receive() by correlationId?

I need something like receive(MessageSelector selector), or an other solution.


Bye,


János

[oleg.zhurakousky]

As far as short reply the answer is "no", this functionality is not currently available. We will think about it for 2.0 release, however I would like to ask:
Let's assume this functionality is available, what (in your view) should happen to all other messages on the channel? Do you expect them to be discarded after a certain timeout? Should they remain on the channel indefinite?
The reason why I am asking is that there might be a surrogate way of implementing what you are looking for.

[exe]

Thx for the answer.

I have a typical request-reply scenario:

flow.jpg


I have 2 problems with the temporaly reply channels

1. How can i rebuild the temp channel, when I deserialize the integration node (while i have to wait for the async reply i want to serialize the service node, and when the result arrived i deserialize the service node and send the result to the tempChannel, consequently i have to deserialize the replyTo channel object) ? Now i think i cannot rebuild the temp channels (it hasn't a channelName) i have to store the replyChannels in a static Map.
   
2. The integrations could handle 1000 or more temp channels?

I expected the integration queue is working like a typical jms queue.
The timeout can be good, but I thaught I can purge the expired messages with UnexpiredMessageSelector.

Thx,

János

[exe]

Hi,


We made some changes on our concept, and we don't need this feature now.


Thx for the help.


János

[Mark Fisher]

Okay. If you are able to provide some information about the approach you are taking, that would be interesting and potentially valuable feedback for us.

Thanks,
Mark

[exe]

Sure, we will describe our old and new architectures as soon as possible. We are in the process of completion of our messaging.

János

[exe]

Our service activator wants to call a new service (asynchron service call).

The tasks are:
1. let the service activator create a new asynchron request
2. make the way for the response to find its way back to the SA


First we tried to implement the service calling logic right into the service activator, but we had problems with that architecture (request reply correlation).sa_call.jpg


In the new architecture the SA just indicates its new service request and the new outbound router forwards a service call request to an other service activator.deferred_call.jpg


János