FWIW, I'll try to respond to both Scott and Matt. Say we have a bi- directional interface consisting of FI.cf and BI.cb, where FI is the forward half and BI is the backward half. We agree that both the call forward method cf and the callback method cb return void. If the call to FI.cf blocked, the question then would be until when and what for? Since the result to cf will be coming in the invocation to cb, there seems to be no purpose in blocking cf, and unblocking it would require some coordination, e.g. with the call to cb, by the system. As for the call to cb (by the service that implements cf) the local implementation is actually blocking, it does not seem to be necessary to spawn another thread for this. Does this address what you were trying to get at?
Given the above, the connector assumes that a bi-directional interface is non-blocking an inserts a NonBlockingBridgingInterceptor, which in turn assumes that the return type of the forward call is void and thus returns a message with a null body, which is probably the cause of your NPE. On 1/12/07, Matthew Sykes <[EMAIL PROTECTED]> wrote:
Jim, I'm interested in the answer to this as well. I think we all understand that non-blocking operations must have void return types. The question really boils down to whether or not bidirectional services are considered non-blocking. I have a simple piece of code that uses a bidirectional service in which the service and callback operations both return data. The code currently fails with an NPE because the ConnectorImpl code uses the NonBlockingBridgingInterceptor when a callback is defined. I can't see anything in the spec that would preclude this. Thanks. Scott Kurz wrote: > Jim, > > OK, but are all callback operations necessarily non-blocking? > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
