| Summary: | the_servant in Servant_Locator::postinvoke is zero when preinvoke throws OBJECT_NOT_EXIST | ||
|---|---|---|---|
| Product: | TAO | Reporter: | milan.cvetkovic |
| Component: | POA | Assignee: | DOC Center Support List (internal) <tao-support> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.5.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 2511 | ||
| Bug Blocks: | |||
| Attachments: |
Suggested fic
Test case exposing where postinvoke's the_servant is zero |
||
Created attachment 607 [details]
Suggested fic
Created attachment 608 [details]
Test case exposing where postinvoke's the_servant is zero
accept on behalf of support, corrected component acept again Wed Feb 21 12:23:12 UTC 2007 Johnny Willemsen <jwillemsen@remedy.nl> * tests/POA/Bug_2511_Regression/server.cpp: Return the error count, in case of a failure then the test framework will notice this * tao/PortableServer/RequestProcessingStrategyServantLocator.cpp: Don't call postinvoke when we don't have a servant. Fixes bugzilla bugs 2511 and 2658. Thanks to Martin Cornelius <Martin dot Cornelius at smiths-heimann dot com> and Milan Cvetkovic <milan dot cvetkovic at mpathix dot com> for reporting this and providing a test case and a proposed fix. |
TAO VERSION: 1.5.1 ACE VERSION: 5.5.1 HOST MACHINE and OPERATING SYSTEM: Sun Sparc Solaris 8 COMPILER NAME AND VERSION (AND PATCHLEVEL): g++-2.95.2 THE $ACE_ROOT/ace/config.h FILE: config-sunos5.8.h THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE: platform_sunos5_g++.GNU AREA/CLASS/EXAMPLE AFFECTED: ServantLocator DOES THE PROBLEM AFFECT: EXECUTION SYNOPSIS: Occasionally, my ServantLocator receives postinvoke with the_servant set to zero. DESCRIPTION: My servant locator occasionally throws OBJECT_NOT_EXIST. I was not expecting that in this case ServantLocator::postinvoke would be invoked. However, it is being invoked with the_servant parameter set to zero. According to the spec: Well, it seems that TAO does it that way, but this behavior is not compliant to CORBA spec. In 04-03-12.pdf, Section 11.3.7 "ServantLocator Interface", the last paragraph: >> If preinvoke raises an exception, postinvoke is not called. Otherwise >> the preinvoke and postinvoke operations are always called in pairs in >> response to any ORB activity. In particular, for a response to a GIOP >> Locate message a GIOPconforming ORB may (or may not) call preinvoke to >> determine whether the object could be served at this location. If the >> ORB makes such a call, whatever the result, the ORB does not invoke a >> method, but does call postinvoke before responding to the Locate >> message. WORKAROUND: (possible workaround) add "if (the_servant)" in the body of my postinvoke function.