| Summary: | IR crashes when invoking more than one oneway call in a row. | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Nanbor Wang <brunsch> |
| Component: | Implementation Repository | Assignee: | Nanbor Wang <brunsch> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | P2 | ||
| Version: | 0.4.2 | ||
| Hardware: | x86 | ||
| OS: | Windows NT | ||
| Bug Depends on: | 256, 303 | ||
| Bug Blocks: | |||
|
Description
Nanbor Wang
1999-08-06 13:02:38 CDT
I haven't had the time to duplicate it yet, but this isn't covered by my tests yet. Excerpt from one of coryan@cs.wustl.edu emails: Well, it is always going to be problematic to use oneways with the IR because the client will not wait for the LOCATION_FORWARD reply, hence it will never know where is the server running and where to issue new requests. The way around this problem is to issue a _non_existent() request (or another twoway call) to check if the object is there, hopefully not on every call, just when the server is down (say because a oneway returned TRANSIENT). I don't think this should be done by the ORB but rather by the application, which knows what is the right thing to do and when does this policy apply. Another solution is to implement reliable oneways as specified in CORBA Messaging. In this case the client do wait for a reply from the server, so there is opportunity to send back a LOCATION_FORWARD message. Notice that you don't wait until the request completes, just until it starts (or even before that) so the client does get some level of asynchrony. Reliable Oneways fixes this. But before this bug can be closed, it has to be tested and verified. |