Service Activator on void method

[jblouirrita]

I have been having trouble off and on with this, and at first it seemed like spring integration broke altogether when using a service activator on a function with no return value (void).

So a typical use case would be...

IUserDAOGateway.updateUser(someModel);

So starting from the gateway we go through the messaging system and end up at the actual Service Actviator / UserDAO which then updates the user and has no return (void).

What is the expected behaviour here because the spring integration manual doesnt clearly explain anything about void methods, is this supposed to work fine? Or should I be using an out-bound channel adapter? (Which is broken btw, expressions do not work which means I have to force the receiving method to handle the actually message object binding me to the spring framework which isnt great . )

Also has anyone ever had problems with going through two gateways? For example I have a Credentials Authenticator Service which contains an ILoginManager interface (gateway injected), and I make a call to the loginmanager (which goes through the gateway) and then the LoginManager makes a call to ISessionManager (another injected gateway) but I keep getting this problem with unexpected return values but everything looks fine I always return the correct payload that the function call on the interface is expecting.

I guess to summarise...

Can the call stack go through multiple gateways without any issues.
What is the correct way to activate a void function.

And if there isnt anything wrong with that then I must be doing something wrong.

I would be very grateful if anyone has any advice! I appear to be on Spring Integration 2.0.4 if thats any help. Thanks!

[oleg.zhurakousky]

Well, Service Activator is one of the MessageHandlers and MessageHandler defines a single method:

void handleMessage(Message)

The main point is that Message exchange is *always* unidirectional. If you are expecting a reply, that is still a Message sent in one direction (oposite in this case). Now in Spring Integration even though we do allow POJO way of implementing MessageHandlers one must still be aware that such POJO will be part of the Messaging system. So void service-activator method is no different than the MessageHandler method above. The Message will be sent and no reply is expected.
Non-void method would signal to the framework that this invocation has produced some value that needs to be sent as a reply. At that point the framework will check if 'output-channel' attribute or 'replyChannel' header is available and will send a Message created from the value produced by this service activator to such channel.

[jblouirrita]

Thanks Oleg, it suddenly clicked when I read your other post which nearly made my eyes fall out my head

1. Send only:
public void foo(Object whatever);

2. Send and Receive:
public Object foo(Object whatever);

3. Receive only:
public Object foo();

because to do the third option would mean that I would need to have asynchronous messages or something, which means that the messages I send around could get mixed up and given to the wrong people.

I am setting up a web server with spring integration on a highly concurrent system where multiple users will be accessing the system all at the same time. I really like spring integration, but my entire architecture that I have set up is set to fall apart completely as I didnt realise this issue and it doesnt seem to be mentioned anywhere in the integration manual. I was expecting to have a nice was of seperating out calls on my interfaces (using gateways) so that I could do some a.o.p work on the function calls but now im worried that the integrity of the entire messaging system is in jeopardy as it doesnt sound like the messages themselves are going to return to the correct calling thread (the thread that made the function call on the gateway).



As I see it now, the only way I can possibly hope to make sure that I received the correct messages is using option #2, so the gateway sends a message and expects a reply, and "hopefully" will only grab the reply message that it is expecting and not some other threads message.

But this also means that all of my function calls need to be non-void and take atleast 1 argument, however I suppose I could get away with update functions that return void since I dont care about receiving a message back