Single-Request/Multiple-Response

[vromero]

I have a request that will return a response with a huge array that potentially can be bigger than the total amount of memory of the receiver.

If I'm not wrong the old streaming support of AMQP is gone.

So I need what in telecommunications is called "Single-Request/Multiple-Response" and in BPEL "one request, Multiple Responses".

For what I see on the source code of the gateway and the adaptors (I can be wrong, I'm not good at SI source) there is no support for it. Am I right?

Before I start writing my own solution, do you agree the best solution could be extend the gateway to not to close communications till a special (return true for a passed expression) message arrives?

Thanks in advance.

[Gary Russell]

If I understand you correctly, you want to generate multiple replies to a single request message.

If so, then, no, the gateway does not support that; it is for a strict request/reply scenario.

However, you should be able to achieve what you want with channel adapters - receive the request on an inbound channel adapter and send as many "replies" as you want to the outbound adapter.

You may need to inject a channel (or preferably a messaging gateway) into your service, so you can send the fragments while still processing the original input message. But, regardless, extending the gateway is not the right approach.

If you need more details, I can whip up a quick example using, say, stdin/stdout adapters.

[vromero]

Thanks Gary,

I've already solved the multiple message generation,

What I'm wondering is how to request&receive message without loosing my original context (headers) let me compare two scenarios, one with my (just theorical at the moment) gateway and the other one using adaptors :

Dibujosintítulo.jpg

CopiadeDibujosintítulo.jpg

[Gary Russell]

Ahh; I was thinking of it from the server side - looks like you are the client, right?

I also presume (because of the size), you want to consume each fragment rather than aggregate them back to a larger message.

Does your external service not return the headers? If not, I assume there is something in the data that allows you to correlate the response fragments to the request?

One technique would be to send a copy of your outbound message to a service and feed the replies through a header enricher that uses the correlation data to add the headers back in.

I can show you how, but I'd like to be clear on your requirements before spending too much time on it.

[vromero]

We actually I over simplified the example,

the service at the moment, does return headers but the headers A, B, C I mentioned at images are actually user credentials, so I would like to not to send it to the final service just to have it copied back (well, it might be necessary at the end) but instead to have a "requestor context"

What you propose is to wrap the external service? is it possible to wrap it in a way that it doen't receive the headers but they actually come back (in n messages) ?

Thanks a lot, you're very supportive.

[Gary Russell]

Take a look at this sample here... https://github.com/SpringSource/spri...on-context.xml

You won't be able to use it exactly because you want to enrich the headers of multiple replies, but you can use the same technique to send a copy of the output request to a service; something like this...

public void captureHeaders(Message<?> request) { 
... 
}

public Map<String, Object> getSavedHeaders(Message<?> multiReply) {
    Map<String, Object> headers = lookupSavedHeaders(multiReply));
    if (lastMessage(multiReply)) {
        unSaveHeaders(multiReply);
    }
    return headers;
}

... and then in your reply path...

<header-enricher ... ref="myBean" method="getSavedHeaders" />

[vromero]

Sounds good.

I'm thinking that I could use a claimcheck with remove-message=false in the check-out to reproduce a behavior similar to what you propose but without programing (just theorizing not sure yet if that makes sense).

[vromero]

no-no

check-in doen't accept ID as a parameter, and I need a well known value (like the business transaction id already present in the message) :

/**
* Put the provided Message into the MessageStore. The store may need to mutate the message internally, and if it
* does then the return value can be different than the input. The id of the return value will be used as an index
* so that the {@link #getMessage(UUID)} and {@link #removeMessage(UUID)} behave properly. Since messages are
* immutable, putting the same message more than once is a no-op.
*
* @return the message that was stored
*/
<T> Message<T> addMessage(Message<T> message);