Yeah, to me though, the orthogonality in this case is by choice, not by necessity. I mean, the client would behave asynchronously anyway to handle the callbacks, so it could also handle the response that way. And, orthogonal dimensions imply combinations. So my question is, is the use-case at hand common enough to justify handling the combinations, both at the spec level and at the impl level.
On 1/12/07, scabooz <[EMAIL PROTECTED]> wrote:
Ignacio, It's true that non-void returns are mux with non-blocking, but that's not the point being made. The point is that non-blocking and bidirectional are orthogonal. Dave ----- Original Message ----- From: "Ignacio Silva-Lepe" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, January 12, 2007 1:09 PM Subject: Re: Callback methods w/ non-void return types >I agree with you, the spec does not explcitly rule this out. Although I >have > not participated in spec discussions about this, it seems to me that, > unless > a special type is returned (something like java.lang.concurrent.Future), > non- > void return values and non-blocking are mutually exclusive. Adding > j.l.c.Future > as an option would have to be explicitly specified, so it seems reasonable > to > me to assume that in its absence void should be assumed for non-blocking. > > > On 1/12/07, Scott Kurz <[EMAIL PROTECTED]> wrote: >> >> So Jim and Ignacio are both assuming that each of the "forward half" and >> the >> "backward half" return void. >> >> But I don't see where in any spec this is stated. Where does it say >> that >> in SCA a bidirectional interface can't have one or both "halves" >> returning non-void data? >> >> >> On 1/12/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: >> > >> > 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] >> > > >> > > >> > >> > >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
