Bug 858

Summary: SYNC_NONE policy semantics do not conform to the spec
Product: TAO Reporter: Carlos O'Ryan <coryan>
Component: ORBAssignee: DOC Center Support List (internal) <tao-support>
Status: RESOLVED FIXED    
Severity: blocker CC: parsons
Priority: P3    
Version: 1.1.14   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 132    

Description Carlos O'Ryan 2001-04-11 11:50:32 CDT 
The CORBA specification requires the ORB never to block on SYNC_NONE requests:

-------------------- formal/01-02-01 Section 22.2.2.1 --------------
SYNC_NONE - equivalent to one allowable interpretation of CORBA oneway
operations. The ORB returns control to the client (e.g., returns from the method
invocation) before passing the request message to the transport protocol.
****** The client is guaranteed not to block. ***** Since no reply is returned
from the server, no location-forwarding can be done with this level of
synchronization.
-------------------- formal/01-02-01 Section 22.2.2.1 --------------

However, the default configuration of TAO for SYNC_NONE (i.e. without an
explicit buffering strategy) blocks the ORB.  I will commit a regression test
shortly in $TAO_ROOT/tests/Blocking_Sync_None

Making the request non-blocking is not really that hard, we could simply put it
in the queue and forget about it (i.e. we could make Eager Buffering the
default).  The question is how to guarantee progress:  without the fixes for bug
132 we need an intermediate twoway or something to guarantee that the queue is
flushed.  With the changes for bug 132 we need somebody to call the reactor
event loop.

I need to know what the plans are for this bug so I can take appropriate action
in the fix_bug132_iter03 branch.
Comment 1 Carlos O'Ryan 2001-04-11 12:00:40 CDT 
Add dependency between 132 and 858.  BTW, the regression test is already in the
repository.
Comment 2 Nanbor Wang 2001-04-11 12:33:55 CDT 
Made it a  blocker
Comment 3 Carlos O'Ryan 2001-04-12 22:12:46 CDT 
FWIW: it is trivial for me to implement the specified semantics on the 132
branch.  Since all I/O is non-blocking in the branch I simply try to write and
if the write returns EWOULDBLOCK the message is queued and handle_output() is
enabled.

Would this be an acceptable implementation?
Comment 4 Irfan Pyarali 2001-04-13 01:21:44 CDT 
Right, SYNC_NONE policy semantics do not conform to the spec because
when this feature was implemented, there was no concept of
non-blocking writes.  The only way to accomplish this was through
timeouts.  See tests/Timed_Buffered_Oneways for an example.

Once you have non-blocking I/O, the sync strategies can check for
EWOULDBLOCK in addition to the existing check for ETIME.  If there was
a timeout or flow control, the message would get queued up for later
delivery.
Comment 5 Carlos O'Ryan 2001-04-20 17:41:57 CDT 
FWIW, this is exactly how things are working in the 132 branch.  This bug report
will be resolved as soon as 132 is.
Comment 6 Carlos O'Ryan 2001-04-24 13:54:49 CDT 
The regression test "almost" passes, occasionally the application blocks, but I
suspect this is more of an scheduling problem than anything else. I'm marking
the bug as fixed, we can re-open it later if we need to.