This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Transmitting Locale and other ctx alongside a messagePage Title Module

Transmitting Locale and other ctx alongside a message

Apr 28th, 2008, 08:23 PM

What is the recommended approach for transmitting Locale and other context information with a message?

This might sound simple in principle and perhaps it is but consider ..

An application that supports many Locales and many industries. Each industry has its own set of terminology. So when a user logs in they see industry terminology and language pertinent to who they are. This much can be achieved with a specialised ResourceBundle.

But as part of that user's webflow they generate several messages that are processed asynchronously. Some of those messages may result in a document or email being generated and dispatched to a user that displays content generated in the context of an industry and Locale. Generally this would be the same context as that of the originating user.

So what is the best mechanism for transmitting that context along with the message? Adding it to all messages seems a little heavy handed and warps the business intent of the message. Is there a better approach?

Processing servers might be a few, which means they wold have to handle the load from multiple geographical locations with different Locales

Correct? (if yes continue. . .)

I agree, sending locale with the message is not the right approach, but not because it could be heavy. I think the server first must be ready to process such requirement. Just because I'll send some locale info doesn't mean that server is capable of interpreting it. Which means there has to be some type of Map of supported Locales and such Map should exist somewhere on the servers and all you need to include in your message is just a key for a locale (i.e., US)

Comment

I really need to know in which Thread the ChannelInterceptor's pre/postReceive methods will be called. IMHO this is a crucial question.

If the ChannelInterceptor's pre/postRecieve method are called by the Channel's dispatcher Thread then there is no way to generally configure Thread context based on the Message as the endpoint will use the Thread of the endpoint's Scheduler.

The ChannelInterceptor callbacks for message reception will indeed be invoked in the dispatcher thread (since it is the one invoking receive). It is therefore correct that the endpoint's handler *may* be invoked in a different thread. This would be the case if the endpoint has a concurrency policy (otherwise, the handler itself is invoked in the dispatcher's thread as well).

If you want to pass a value from the sender's thread to the handler, then storing that as a Message attribute value might be the right approach. We are adding interceptors for endpoints as well, so once this is in place, it should be easier to propagate values transparently (is this your general goal?).

The sequence diagram is an excellent idea, and we will include this (along with more architectural diagrams/discussion in general) within the next milestone release. The model has been in a state of flux but with the upcoming M4 release, these diagrams will be very useful.

Regards,
Mark

Comment

To answer your question, yes, propagating values transparently is the goal.
So having an EndpointInterceptor or an interception point that will be executed by the Thread consuming the message seems like a good idea.

So this would mean that I would need a ChannelInterceptor to add the context to the message and an EndpointInterceptor to retrieve the context from the message.

An alternate would be to have the ChannelInterceptor called by the consuming Thread. If there is no Endpoint concurrency policy then as you point out, this is the Channel Dispacther, otherwise it would be an Endpoint Scheduler Thread. This would also make the invocation of the ChannelInterceptor symmetrical, ie called by either produciong or consuming Thread by never by a Dispatcher that does also consume. But this may not fit well with the rest of the SpringIntegration design.