Summary: | is_a infinite loop due to socket creation timeout & try_rebind | ||
---|---|---|---|
Product: | JacORB | Reporter: | Richard Ridgway <Richard_Ridgway> |
Component: | ORB | Assignee: | Gerald Brose <gerald.brose> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jacorb |
Priority: | P2 | ||
Version: | 2.3.0 | ||
Hardware: | PC | ||
OS: | All | ||
Bug Depends on: | |||
Bug Blocks: | 896 | ||
Attachments: | Patch to Delegate class to fix infinite loop bug |
Description
Richard Ridgway
2007-11-12 22:29:02 CET
Things I don't understand that prevent me writing a patch I'm confident to submit: 1) Why would we ever set piorOriginal=null after we have set it originally. 2) How can we make this work when locate_on_bind is false? Initial forwarding is ok, and genuine failover and rebind to new ior is ok, but what happens if I have a genuine temporary comms problem, ImR reforwards me to the /same/ ior=piorLastFailed again, how do I know not to refuse to go to it... Unrecoverable failure is better than infinite loop, but not much. Created attachment 391 [details]
Patch to Delegate class to fix infinite loop bug
Attached a patch that applies to the org.jacorb.orb.Delegate class in the method 'public boolean is_a( org.omg.CORBA.Object self, String logical_type_id ). It adds a counter to the while loop at the end of the method that causes it to terminate after 5 iterations to prevent an infinite loop. The patch is based off of the 2.3.0 release of jacorb and not the latest 2.3.1 release, but it's simple enough to apply manually.
It's probably not an ideal solution, but it gave us a quick fix that we needed for this issue. Submitting it for consideration for the next planned release of jacorb in hopes that either it will be accepted as a fix or that it will prompt a better fix to be found.
I've added a patch to the Delegate class to address this bug. Since there are several builtin operations that could potentially trigger the same infinite loop, I created a helper function that encapsulates the desired behavior, and applied the fix there. Also, to ensure no change to the status quo, I added a configuration property, jacorb.maxBuiltinRetries, to allow users to specify a limiter. No value set will cause the loop to retry forever. Search for this property in etc/jacorb_properties.template for an example of its use. Note that this is really an interim patch addressing a symptom of a larger problem. The larger problem is that of errant interaction with at least the TAO ImR and servers attached to the same. Part of that behavior is also captured in bug 896. The proper solution, which will likely render this fix redundant, I believe is sufficiently difficult as to require funding to develop. Please visit the support page of jacorb.org to contact a company to work who can develop a proper solution. |