| Summary: | Possible bug in timeout buffering constraint implementation | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Carlos O'Ryan <coryan> |
| Component: | ORB | Assignee: | Irfan Pyarali <irfan> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.1.14 | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 132 | ||
Just adding the fact that 132 depends on this bug. Here is what is going on: - The oneways gets queued. It doesn't take too long to queue a oneway. - After about 50 msec, the timeout occurs. The ORB uses the twoway to the admin to flush the oneway message. During these 50 msec, your test queues up a bunch of messages (about 200 messages on my laptop). - During the twoway in which the flushing occurs, the admin still thinks that no messages have been delivered to the server. - The flushing of these queued messages takes time. Eventually, the elapsed time goes over the threshold, the test thinks that no message was delivered to the server, and thus reports failure. You are sending too many oneways. I would pace them - maybe give the ORB a chance to run (see examples/Buffered_Oneways/client.cpp for example). FWIW: in the 132 branch the test passes, instead of just using the reactor to trigger the flushing we also check the timeout on each request. If the timeout has expired (even though the Reactor may have not had a chance to run it) the ORB starts flushing the queue. I believe the test to be valid, and a good use-case for some applications (applications that periodically send data at fixed rates), once the branch is merged the test will become part of the regression testsuite. |
This may be a misunderstanding, but I expected the BUFFER_TIMEOUT buffering constraint policy to behave differently. As it stands today even my regression test in $TAO_ROOT/tests/Oneway_Buffering does not pass. The test works as follows: 1) Set the buffering constraint policy to a timeout (a nice 50 milliseconds interval) 2) Flush the queue and synchronize with the server 3) Record the current time <start> 4) Send oneway messages and detect when the first new message arrives to the server. 5) If the elapsed time since step (3) is less than the buffering timeout flag this as an error. 6) If the elapsed time is too long and nothing has been received that's an error too ("too long" is twice the interval, just a guess). Is this test incorrect? If so: what are the exact semantics that should be implemented? Need to know in order to make the 132 fixes compatible.