| Summary: | Possible codeset problem when using oneways | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Johnny Willemsen <jwillemsen> |
| Component: | ORB | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.5.10 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Johnny Willemsen
2007-08-22 09:23:36 CDT
corrected summary I think that for all connection-oriented transports (all except DIOP?) this should not be a problem. An undelivered oneway might be queued for later sending, in which case a subsequent invocation would cause it to be sent. Or maybe the send fails due to a communication problem, in which case a new invocation would again be the first on a newly re-established connection and again carry the codeset context info. Since the decision to send codeset context info happens very late, as a message is being packaged for send, I think that even if a oneway were discarded due to some policy, such as a timeout, this would happen before the decision to apply codeset context info to the message. As I recall, DIOP is not connection oriented, and so it might suffer the fate you describe. But even then, TAO relies on default codeset information if no context is received, so there would only be trouble if a non-default codeset were being configured. Since there is no way for the server to ACK a codeset context, I think the only way to really address this problem would be to repeatedly send the codeset context, but I think that would have a significant negative impact on performance. what about changing the flag first message to something else. For example an enum with some states. First, not send, if we then get a oneway, we add the service context to each oneway until we have reached the first twoway, then we do it once again and then not anymore. I haven't checked the exception path, but if things fail during connection setup we have to make that we handle that correctly |