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.

Then, the server seems to be sleeping, while the client has splitted and routed all messages. Only if I stop the server, the client will try sending the other messages and get an error since the server is down.

Does anyone knows why the server is blocking on each channel and how to avoid this?

Perhaps we should consider defining 'expect-reply' as a required attribute in the XSD. Even though it is a simple boolean, this might help to clear up the confusion, and arguably, there is no strong default value. What do you think?

Comment

This is an interesting question. A "true" default value makes sense when the call is returning something. But with a void type, a "false" default value seems to make sense. However, I can imagine examples where we would want a void reply (to make the call synchronous) or where we would want to ignore a returned value (although I would probaly not advocate this kind of use case).

In fact, I do not know Spring-Integration enough at that time to say if a default value is a good thing for this property. It seems that having no default value would probably help in learning the way it works by making the value explicit to the programmer.

Beside this, what would probably be the more usefull is a reference of all elements and properties with an explanation of the way they should be used, but I understand it is a big job with a low priority. Reading the XSDs does the job, as long as the reader understands it, which was not my case for this problem. But because of this problem, and with your help, I have learnt not only how rmi-gateway works but also how xsd:extension (and BTW xsd:restiction) works. So, for me, it's perfect like this.

Pierre-Yves

Comment

This is an interesting question. A "true" default value makes sense when the call is returning something. But with a void type, a "false" default value seems to make sense. However, I can imagine examples where we would want a void reply (to make the call synchronous) or where we would want to ignore a returned value (although I would probaly not advocate this kind of use case).

In fact, I do not know Spring-Integration enough at that time to say if a default value is a good thing for this property. It seems that having no default value would probably help in learning the way it works by making the value explicit to the programmer.

Beside this, what would probably be the more usefull is a reference of all elements and properties with an explanation of the way they should be used, but I understand it is a big job with a low priority. Reading the XSDs does the job, as long as the reader understands it, which was not my case for this problem. But because of this problem, and with your help, I have learnt not only how rmi-gateway works but also how xsd:extension (and BTW xsd:restiction) works. So, for me, it's perfect like this.

Pierre-Yves

I think you could better learn the xsd fine with Ctrl-Space in eclipse (that would show you the attribute without you having to parse the xsd in your head), the SpringSource Tool Suite does this out of the box, but with a vanilla Eclipse you have to add wtp I think. Reading xsd might be a useful exercise, but it is definitely time consuming.

As for the defaults, I am in love with sensible defaults. What's wrong here with SI's behavior is that:

it assumes you want a reply while it doesn't create a reply out of void

it doesn't time out (with a descriptive error)

Especially the first point bugs me because SI could have known that it wasn't going to work, right? (Figuratively speaking of course)

Your response makes me think there is a more elegant set of defaults that would resolve the problem than just making the attribute required, although that would work better than what we have now.

As for the defaults, I am in love with sensible defaults. What's wrong here with SI's behavior is that:

it assumes you want a reply while it doesn't create a reply out of void

it doesn't time out (with a descriptive error)

Especially the first point bugs me because SI could have known that it wasn't going to work, right? (Figuratively speaking of course)

I don't see how it could know actually. All that the gateway knows in this example is the 'requestChannel'. If the ultimate receiver is a void-returning method, then no reply would be sent. The problem is that the gateway has no idea what that ultimate receiver is. Adding 'expect-reply=true' is telling the gateway to provide a returnAddress prior to sending the Message and then to wait (up to the timeout) for a reply.

Maybe a clearer approach would be to provide an RMI "source" in addition to the gateway. Using gateway would always assume request/reply, but source would always imply "one-way".

Another consideration would be to always return a reply even if just a "status" Message, but obviously that type of change would extend well beyond just the gateways.

Comment

I don't see how it could know actually. All that the gateway knows in this example is the 'requestChannel'. If the ultimate receiver is a void-returning method, then no reply would be sent. The problem is that the gateway has no idea what that ultimate receiver is.

Well, it is quite unreasonable, but to the user it would seem that if you view Spring Integration as a big black box you might expect it to understand about the relationships between components at configuration time, even if they are separated by a channel. You're probably right if you don't want to complicate things that far.

Comment

I think you could better learn the xsd fine with Ctrl-Space in eclipse (that would show you the attribute without you having to parse the xsd in your head), the SpringSource Tool Suite does this out of the box, but with a vanilla Eclipse you have to add wtp I think. Reading xsd might be a useful exercise, but it is definitely time consuming.

I feel reading the XSD is definitely worth the time spent on it. I allows to learn the relationship between the various elements wether using Ctrl-Space in Eclipse only lists the properties without showing where they come form. But this is a matter of taste.

Especially the first point bugs me because SI could have known that it wasn't going to work, right? (Figuratively speaking of course)

This would be smart, but wouldn't it be too smart? As it is, it fails, but I eventually know why an can deal with it. If SI was to decide on itself if a reply is expected, it would work and I would not know why. The problem is it might not work the way I intended.

I modified the example to make the method return a value, although I still do not want the value to be returned by the gateway. If SI was to decide, it would see that the method is returning a value and it would configure the gateway accordingly, which is not what I want in my new use case. So, I would need a way to overide this behavior.

This could be done by letting SI decide from the method in case the expect-reply attribute is not present, and conform to the attribute value if present.

This is a bit complicated and would probably lead to a situation of "positive error" where the application works as expected, but for a different reason than what was intended. This might break when the application is later modified.

So, my preference would go to no default value, which makes things more explicit.