How not to send message?

[Cleric]

Ok.
Maybe it's enough:

 if (n == 0) {
                // HERE IS PROBLEM!!! What should i do to correctly say to Spring - no message exist, continue work without Exceptions
                // throw new SoftEndOfStreamException("No data are readed from channel");
                return "NO MESSAGE EXIST".getBytes();
            }

[Gary Russell]

// HERE IS PROBLEM!!! What should i do to correctly say to Spring - no message exist, continue work without Exceptions

I couldn't disagree more!

Using an exception to convey information to something further down the stack is entirely legitimate.

Otherwise, you'd have to pass and test some 'special' return value (such as null) in *every* stack frame on the way down. In this case, the exception tells the framework that the socket was closed in an orderly fashion, and we can clean up properly. The intervening frames don't care about the condition.

We don't incur any additional overhead because we have to catch IOExceptions anyway (SEOSE is a subclass of IOException).

You don't need to worry about it being logged; we consume the exception at the appropriate stack frame; it is not logged; as I said it is used to convey information. Aside from not having to worry about the condition in all the stack frames between convert() in the connection and the low-level code in the deserializer; I feel it conveys more semantic value than, say, returning something like null or some other special value.

It is clearly documented in the javadoc for the exception as well as in the javadoc for the deserialize() method in our serializers.

If you used our serializer as a base, I don't see why you didn't use that part of the code.

You can disagree if you like, but if you want to avoid the 'can't send null' message, you need to throw the exception if the socket is closed before any part of a message is received.

HTH

[Ru.Lazukov]

Yes, it's possible but it's bad decision.

Data from TCP channel goes to JMS and stores until processing service. So this "NO MESSAGE EXIST" will be stored in JMS saved to log file, to HDD... then readed from HDD and send to JMS-receiver.

Also possbile situation that for one package of real data will be 10 "NO MESSAGE EXIST". This mean that JMS server will store huge amounts of useless messages, cunsuming CPU and IO resources.

[dnlegge]

I have to agree with Gary, and he's given you a good solution. The serializer's job is to make sense of what's on the channel, it shouldn't be making business decisions as to whether what it gets is sensible (cf Separation of Concerns). At the (low) level of abstraction of a serializer, receiving null is exceptional. You may want to use it elsewhere when your solution wouldn't make sense.

Cleric's earlier answer ("Your can define on your tcp-adapter an error-channel.") may give you a way to avoid the waste of JMS resources, otherwise it seems a problem with your stream rather than with Spring; presumably you've looked into improving that already.

David