[Ace-users] Policy creation failures (Security, Messaging)
swara101 at yahoo.com
Mon Nov 19 22:12:02 CST 2007
On Nov 19, 1:34 am, Jochen Rothenbacher <jochen.rothenbac... at nsn.com>
> are there any news regarding the problem of using strategies and messaging?
> I'm asking because I've also have problems using Receive-Wait(RW) wait
> strategy (see attached posting) and messaging.
> Johnny Willemsen wrote:
> > Hi,
> > I have seen recently a problem with strategies and messaging, but security
> > and messaging should work.
> > Regards,
> > Johnny Willemsen
> > Remedy IT
> > Postbus 101
> > 2650 AC Berkel en Rodenrijs
> > The Netherlands
> > *** Integrated compile and test statistics see
> > *** Commercial service and support for ACE/TAO/CIAO ***
> > *** Seehttp://www.theaceorb.nl/en/support.html ***
> > "Venkat" <swara... at yahoo.com> wrote in message
> > <news:1193806055.319689.316920 at i38g2000prf.googlegroups.com>...
> >> Hello TAO team,
> >> Following is the PRF details for the problem
> >> TAO VERSION: 1.6.1
> >> ACE VERSION: 5.6.1
> >> HOST MACHINE and OPERATING SYSTEM:
> >> amd64, NetBSD 3.1
> >> TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> >> same
> >> THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
> >> specific file, simply state which one]:
> >> config-netbsd.h
> >> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE :
> >> platform_netbsd.GNU
> >> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
> >> ssl=1
> >> AREA/CLASS/EXAMPLE AFFECTED:
> >> COMPILATION? No
> >> LINKING? No
> >> EXECUTION? Yes
> >> Application - Messaging and Security Policy configuration failure
> >> SYNOPSIS:
> >> Setup application with SSLIOP secuirty. Configuration of various
> >> policies on the orb has a problem.
> >> DESCRIPTION:
> >> Built an application with SSLIOP security. Following security policy
> >> creation works....
> >> any_val <<= Security::SecQOPIntegrityAndConfidentiality;
> >> orb->create_policy(Security::SecQOPPolicy, any_val);
> >> However, creating the following policy causes policy error. Actually,
> >> any Messaging policy setup is failing.
> >> orb->create_policy(TAO::CONNECTION_TIMEOUT_POLICY_TYPE, cany_val);
> >> I ran TAO/tests/AMI_Timeouts to see whether Messaging policy has a
> >> problem. The test runs without a problem.
> >> It seems the combination of security and Messaging has a problem. Any
> >> ideas what could or should be helpful to narrow it down?
> >> REPEAT BY:
> >> SAMPLE FIX/WORKAROUND:
> >> None.
> >> Thanks
> >> Venkat
> [ Attached Message ]From:Jochen Rothenbacher <jochen.rothenbac... at siemens.com>To:Date:Thu, 25 Oct 2007 15:24:46 +0200Local:Thurs, Oct 25 2007 5:24 amSubject:Relative round-trip timeout policy not compatible with Receive-Wait(RW) wait strategy ACE VERSION: 5.5.6
> HOST MACHINE and OPERATING SYSTEM:
> sun solaris 10
> TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> COMPILER NAME AND VERSION (AND PATCHLEVEL):
> CC: Sun C++ 5.7 Patch 117830-08 2006/07/12
> THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
> specific file, simply state which one]:
> #include "ace/config-sunos5.10.h"
> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
> use a link to a platform-specific file, simply state which one
> (unless this isn't used in this case, e.g., with Microsoft Visual
> include $(ACE_ROOT)/include/makeinclude/platform_sunos5_sunc++.GNU
> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
> (used by MPC when you generate your own makefiles):
> DOES THE PROBLEM AFFECT:
> No exception is raised in client calls if timeout occurs.
> Using the Receive-Wait(RW) wait strategy prevents the raising of
> timeout exception.
> When using the Receive-Wait(RW) wait strategy I observed that no
> CORBA::TIMEOUT exception was raised.
> Is the relative round-trip timeout policy not compatible with the
> RW strategy?
> Best regards,
My original post was basic usages of messaging and security policies.
They are working now. Cause apparently was static ctor activation
issue on NetBSD. Someone in our group resolved them.
More information about the Ace-users