| Summary: | use Reactor to send instead of blocking directly on writev | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Ossama Othman <ossama.othman> |
| Component: | ORB | Assignee: | Carlos O'Ryan <coryan> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | ||
| Priority: | P2 | ||
| Version: | 1.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 575, 842, 858, 863, 886 | ||
| Bug Blocks: | 583, 393 | ||
|
Description
Ossama Othman
1999-07-26 17:26:32 CDT
This is a valid enhacement request, i'm marking it as accepted but their implementation is deferred I'll take care of this one. BTW, the same issue applies to connects. Simply accepting the bugs. I don't have time to work in this back at any point in the foreseeable future. I'm returning the bug to the main pool, if anybody wants to take it they are welcomed to ask questions on how to approach the problem/enhancement. Bugs moved to the tao-support placeholder. I've been working on this one for the last couple of weeks.
The current design considers:
- Each transport will contain a queue of messages.
- Each message can have a different timeout.
- Some messages (twoways) wait for the event, potentially using the
leader/follower protocol.
- The twoway waiters should wake up if:
+ The message is sent
+ The connection is closed or fails
+ The message times out
- AMI requests have similar signaling needs.
- Some applications may not want to use the reactor
- Oneway requests can be buffered or not, depending on the policies in place.
- The minimum size of the queue can also be controlled by policies
- Memory management and optimizations are critical, will need to pool the queue
nodes and potentially the 'waiting' objects.
- Currently ACE only has a blocking version of ACE::send() that takes a
Message_Block chain. Need to replace it with a non-blocking version.
- Using ACE::send() with an SSLIOP protocol (or SHMIOP protocol) is incorrect,
so the code must be refactored at the Svc_Handler or <IPC>_Stream layer.
Overall the problem is not hard, but it is quite complex and somewhat far
reaching (multiple objects affected, etc.)
This should be a blocking bug for the 1.2 release. I am planning to fix it long before that, but it must be properly recorded. FWIW: the current status in the fix_bug132_iter04 branch is as follows: - All the regression tests pass, including Big_Oneways and Big_Twoways. - Both the Reactive and Blocking flushing strategies work, obviously the Block_Flushing_Strategy is limited in functionality. we need: - A regression test for buffered AMI requests, just like Oneway_Buffering. - More regression tests for the Block_Flushing_Strategy.... - The current implementation adds too much locking overhead, we can share the lock used to access the underlying connection. - The ORB does not flush all its queues when it shuts down... I'm not sure what the right approach is. Another status update: the bulk of the changes are in the main trunk now. I'm going through the build logs, fixing problems and trying to understand why some tests are failing. The bug should be closed one 575 and 886 are closed. The best ETA guestimate is a couple of days after they are closed. Now that 886 is fixed this bug has been fixed too. |