To: tao-bugs@...
Subject: Notify Service: Proxy does not disconnect its peer.

     TAO VERSION: 1.7.3
     ACE VERSION: 5.7.3

     HOST MACHINE and OPERATING SYSTEM: Linux RHEL4 update 6 x86_64
         If on Windows based OS's, which version of WINSOCK do you
         use?:

     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL):
         gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)

     THE $ACE_ROOT/ace/config.h FILE:
         config-linux.h

     THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:
         platform_linux.GNU

     BUILD METHOD USED:
         Traditional.

     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
     (used by MPC when you generate your own makefiles): None

     AREA/CLASS/EXAMPLE AFFECTED:
         Notify Service - Proxy implementation.

     DOES THE PROBLEM AFFECT:
         COMPILATION?
             If so, what do your $ACE_ROOT/ace/config.h and
             $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?
         LINKING?
             On Unix systems, did you run make realclean first?
         EXECUTION?
	     Yes. Affect my app only.
         OTHER (please specify)?

     SYNOPSIS:
	 A Notify Service Proxy never call its peer when disconnecting.

     DESCRIPTION:
	 When a Notify Service Proxy disconnects from its peer, it
	 never call its peer's disconnect_xxx operation.

	 The Event Service specification is very clear about this
	 point. The Notification Service Specification Version 1.1 is
	 much less clearer, but I did a search on Google and found this
	 issue: http://www.omg.org/issues/issue3114.txt that seems to
	 require the proxy to call its peer's disconnect_xxx when they
	 are disconnecting. This may happens as a result of calling
	 directly its disconnect_xxxx operation or indirectly because
	 its Admin (either Supplier or Consumer) or Channel is
	 destroyed.

	 I also looked at the tests provided and found that in the
	 orbsvcs/tests/Notify/Basic/ConnectDisconnect test, there is an
	 assertion to check that the disconnect_xxx operation is NEVER
	 called in the app side, while I would check the contrary: that
	 the disconnect_xxx IS called when I disconnect the proxy. Was
	 it done on purpose ?

     REPEAT BY:
         Just use the orbsvcs/tests/Notify/Basic/ConnectDisconnect
         test. It works, but does not conform to the specification in
         my opinion.

     SAMPLE FIX/WORKAROUND:
         I fixed the problem by adding a "shutdown" method in every
         proxy subclass. Hopefully, this method is virtual so this is a
         very small change. I can send the patch if you agree that this
         is a bug.
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi Didier,

    Thanks for using the PRF.

> TAO VERSION: 1.6.7

Please upgrade to ACE+TAO+CIAO x.7.5 (i.e., ACE 5.7.5, TAO 1.7.5, and CIAO
0.7.5), which you can download from

http://download.dre.vanderbilt.edu

under the heading: "Latest Micro Release Kit."

The DOC group at Vanderbilt University only provides "best effort"
support for non-sponsors for the latest release, as described in

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html

Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out

http://www.dre.vanderbilt.edu/support.html

for a list of companies that will provide you with ACE+TAO commercial
support.

Thanks,

         Doug


>
> HOST MACHINE and OPERATING SYSTEM: Linux 2.6.9-42.ELsmp i686, RedHat ES 4
update 4
>
> COMPILER NAME AND VERSION (AND PATCHLEVEL): g++ 3.4.6
>
> THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>     specific file, simply state which one]: config-linux.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
>
>  C++)]: platform_linux.GNU
>
> BUILD METHOD USED:
> [experimental ./configure or traditional makefile/project file?] : traditional
>
> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>     (used by MPC
>  when you generate
>  your own makefiles):
>
> AREA/CLASS/EXAMPLE AFFECTED:
> [What example failed?  What module failed to compile?]
>
> DOES THE PROBLEM AFFECT:
>         COMPILATION? no
>         LINKING? no
>         EXECUTION? yes
>         OTHER (please specify)?
> [Please indicate whether ACE/TAO, your application, or both are affected.]
application
>
> SYNOPSIS: memory leak in client after calling a oneway operation on a distant
server having a sequence
> of 5000000 octets as parameter
>
>
> DESCRIPTION:
>
> with the following idl:
>
> typedef octet U8;
> typedef sequence<U8,5000000> spectre_pv_t;
> interface IProdSpectrePv {
>  oneway void push(in spectre_pv_t f_spectre_pv_elt_in);
>
> };
>
>
> When the client calls the oneway operation on the server,
> the client process memory increases and the valgrind tool detects the
following memory leak in the "copy_if_necessary" in
> client process
>  :
>
> ==17058== 5,840
>  bytes in 146 blocks are definitely lost in loss record
> 329 of 334
> ==17058==    at 0x4004904: operator new(unsigned, std::nothrow_t const&)
> (vg_replace_malloc.c:180)
> ==17058==    by 0x410AFD1: ACE_Message_Block::clone(unsigned long) const
> (in /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/ace/libACE.so.5.6.7)
> *==17058==    by 0x42876A8:
> TAO_Synch_Queued_Message::copy_if_necessary(ACE_Message_Block const*)
> (in /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so..1.6.7)*
> ==17058==    by 0x429D343: TAO_Transport::cleanup_queue(unsigned) (in
>
> /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by 0x429F085: TAO_Transport::drain_queue_helper(int&,
> iovec*, ACE_Time_Value*) (in
> /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by
>  0x429F7D7:
>  TAO_Transport::drain_queue_i(ACE_Time_Value*)
> (in /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by 0x42A0406:
> TAO_Transport::send_message_block_chain_i(ACE_Message_Block const*,
> unsigned&, ACE_Time_Value*) (in
> /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by 0x42A05A7:
> TAO_Transport::send_asynchronous_message_i(TAO_Stub*, ACE_Message_Block
> const*, ACE_Time_Value*) (in
> /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by 0x42A0C5A:
>
> TAO_Transport::send_message_shared_i(TAO_Stub*,
> TAO_Transport::TAO_Message_Semantics, ACE_Message_Block const*,
> ACE_Time_Value*) (in
> /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by 0x42A0D06: TAO_Transport::send_message_shared(TAO_Stub*,
>
> TAO_Transport::TAO_Message_Semantics,
>  ACE_Message_Block const*,
> ACE_Time_Value*) (in
> /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by 0x42427AE:
> TAO_IIOP_Transport::send_message(TAO_OutputCDR&, TAO_Stub*,
> TAO_Transport::TAO_Message_Semantics, ACE_Time_Value*) (in
> /tools/exec/ACE_TAO_1..6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
> ==17058==    by 0x424274C: TAO_IIOP_Transport::send_request(TAO_Stub*,
> TAO_ORB_Core*, TAO_OutputCDR&, TAO_Transport::TAO_Message_Semantics,
> ACE_Time_Value*) (in
>
> /tools/exec/ACE_TAO_1.6.7/ACE_wrappers/TAO/tao/libTAO.so.1.6.7)
>
> The "copy_if_necessary" operation is called by Transport and produces
> memory leak
>
> REPEAT BY:
>
>
> SAMPLE FIX/WORKAROUND:
>
>
> _______________________________________________
> tao-bugs mailing list
> tao-bugs@...
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi David,

I've seen the same thing as well, i.e. that client-leaders are special
and don't give up leadership in set_upcall_thread - I could find no
reason for this being the way it is though.  I modified my version of
TAO to change this, i.e. client-leader threads can give up leadership,
and I have pasted it below - my version is ancient though (OCI version
1.3a_p10) so you'll have to update it for your version (plus I couldn't
change my ABI so I had to use some hacks to avoid this (setting
client_leader_thread_ to a negative value) - please feel free to update
the patch in this respect if you want).  Once done please submit it for
inclusion in the TRUNK.

HTH

Cheers,
Russell.

Index: Leader_Follower.i
===================================================================
RCS file:
/src/apps/VxPSP/Current/source/ACE_wrappers/TAO/tao/Leader_Follower.i,v
retrieving revision 1.1.1.4
retrieving revision 1.5
diff -u -r1.1.1.4 -r1.5
--- Leader_Follower.i   24 Sep 2004 18:00:55 -0000      1.1.1.4
+++ Leader_Follower.i   24 Oct 2009 09:06:19 -0000      1.5
@@ -3,6 +3,8 @@

  // ****************************************************************

+TAO_BEGIN_VERSIONED_NAMESPACE_DECL
+
  ACE_INLINE
  TAO_Leader_Follower::TAO_Leader_Follower (TAO_ORB_Core* orb_core,
                                            TAO_New_Leader_Generator
*new_leader_generator)
@@ -61,6 +63,8 @@
  ACE_INLINE int
  TAO_Leader_Follower::set_event_loop_thread (ACE_Time_Value
*max_wait_time)
  {
+  // No need to grab the lock here - this method is called from the
+  // LF_Strategy object which has already grabbed the lock.
    TAO_ORB_Core_TSS_Resources *tss = this->get_tss_resources ();

    // Make sure that there is no other client thread run the show.  If
@@ -94,6 +98,9 @@
  ACE_INLINE void
  TAO_Leader_Follower::reset_event_loop_thread_i
(TAO_ORB_Core_TSS_Resources *tss)
  {
+  // No need to grab the lock here - this method is called from the
+  // LF_Strategy object which has already grabbed the lock.
+
    // Always decrement <event_loop_thread_>. If <event_loop_thread_>
    // reaches 0 and we are not a client leader, we are done with our
    // duties of running the event loop. Therefore, decrement the
@@ -133,6 +140,16 @@

        this->elect_new_leader ();
      }
+  else if (tss->client_leader_thread_ > 0)
+    {
+      ACE_GUARD (TAO_SYNCH_MUTEX, ace_mon, this->lock ());
+      this->reset_client_leader_thread ();
+      // We need some way to signal to reset_client_leader_thread that
+      // the leadership has already been given up - we do this by
+      // negating the client_leader_thread_ count.
+      tss->client_leader_thread_ = -tss->client_leader_thread_;
+      this->elect_new_leader ();
+    }
  }

  ACE_INLINE int
@@ -144,6 +161,8 @@
  ACE_INLINE void
  TAO_Leader_Follower::set_client_leader_thread (void)
  {
+  // No need to grab the lock here - this method is called from inside
+  // wait_for_event where the lock is already held.
    TAO_ORB_Core_TSS_Resources *tss = this->get_tss_resources ();
    ++this->leaders_;
    ++this->client_thread_is_leader_;
@@ -153,10 +172,27 @@
  ACE_INLINE void
  TAO_Leader_Follower::reset_client_leader_thread (void)
  {
+  // No need to grab the lock here - this method is called from inside
+  // wait_for_event where the lock is already held.
    TAO_ORB_Core_TSS_Resources *tss = this->get_tss_resources ();
+  // We may have already been called via set_upcall_thread before we
+  // get called via ~TAO_LF_Client_Leader_Thread_Helper, so we need to
+  // check that client_leader_thread_ is not already zero.
+  if (tss->client_leader_thread_ > 0)
+    {
    --tss->client_leader_thread_;
    --this->leaders_;
    --this->client_thread_is_leader_;
+    }
+  else if (tss->client_leader_thread_ < 0)
+    {
+      // If the client_leader_thread_ count was negative that means
+      // that leadership was given up via a call to set_upcall_thread
+      // in this wait_for_event context - reset the value back to its
+      // postive value which is what is required for the next
+      // wait_for_event context up the stack.
+      tss->client_leader_thread_ = -tss->client_leader_thread_;
+    }
  }

  ACE_INLINE int
@@ -217,3 +253,5 @@
  {
    this->leader_follower_.reset_client_leader_thread ();
  }
+
+TAO_END_VERSIONED_NAMESPACE_DECL


Index: Leader_Follower.cpp
===================================================================
RCS file:
/src/apps/VxPSP/Current/source/ACE_wrappers/TAO/tao/Leader_Follower.cpp,
v
retrieving revision 1.3
retrieving revision 1.6
diff -u -r1.3 -r1.6
--- Leader_Follower.cpp 26 Apr 2007 20:56:46 -0000      1.3
+++ Leader_Follower.cpp 27 Jan 2009 16:12:42 -0000      1.6
@@ -161,6 +161,7 @@
    if (tss->event_loop_thread_ ||
        tss->client_leader_thread_)
      {
+      // Will this ever be true?  And will it ever work?
        ++this->leaders_;
      }

@@ -199,16 +200,29 @@
    if (TAO_debug_level)
      t_id = transport->id ();

-  {
+  { // Scope #1: All threads inside here are client threads
      // Calls this->set_client_thread () on construction and
      // this->reset_client_thread () on destruction.
      TAO_LF_Client_Thread_Helper client_thread_helper (*this);
      ACE_UNUSED_ARG (client_thread_helper);

+    // The loop here is for when we get elected (client) leader and
+    // then later relinquish the leader position and our event has
+    // still not completed (and we haven't run out of time).
+
+    // All the conditions below are basically the various ways the
+    // leader loop below can end, other than the event being complete
+
+    while (event->keep_waiting ()
+           && !(result == 0 &&
+                max_wait_time != 0 &&
+                *max_wait_time == ACE_Time_Value::zero)
+           && result != -1)
+      { // Scope #2: threads here alternate between being
leader/followers
      // Check if there is a leader.  Note that it cannot be us since we
      // gave up our leadership when we became a client.
      if (this->leader_available ())
-      {
+      { // Scope #3: threads here are followers
          // = Wait as a follower.

          // Grab a follower:
@@ -228,7 +242,7 @@

          while (event->keep_waiting () &&
                 this->leader_available ())
-          {
+          { // Scope #4: this loop handles spurious wake-ups
              // Add ourselves to the list, do it everytime we wake up
              // from the CV loop. Because:
              //
@@ -324,7 +338,7 @@
                      return -1;
                    }
                }
-          }
+          } // End Scope #4: loop to handle spurious wakeups

          countdown.update ();
@@ -354,7 +368,7 @@
          // We only get here if we woke up but the reply is not
          // complete yet, time to assume the leader role....
          // i.e. ACE_ASSERT (event->successful () == 0);
-      }
+      } // End Scope #3: we are no longer a follower

      // = Leader Code.

@@ -367,15 +381,16 @@
      // construction and this->reset_client_leader_thread ()
      // on destruction.  Note that this may increase the refcount of
      // the leader.
+    { // Scope #5: We are now the client-leader
      TAO_LF_Client_Leader_Thread_Helper client_leader_thread_helper
(*this);
      ACE_UNUSED_ARG (client_leader_thread_helper);

-    {
+    { // Scope #6: release the lock via a reverse lock
        ACE_GUARD_RETURN (ACE_Reverse_Lock<TAO_SYNCH_MUTEX>, rev_mon,
                          this->reverse_lock (), -1);

        // Become owner of the reactor.
-      ACE_Reactor *reactor = this->reactor_;
+      ACE_Reactor *reactor = this->reactor ();
        reactor->owner (ACE_Thread::self ());

        // Run the reactor event loop.
@@ -403,6 +418,16 @@
            if (result == -1)
              break;

+          // Has an event loop thread become available to take over?
+          // Yes, we are checking this without the lock, however, if
+          // we get a false reading we'll just circle around and
+          // become leader again...
+          if (this->event_loop_threads_waiting_)
+            break;
+
+          // Did we give up leadership?
+          if (!this->is_client_leader_thread ())
+            break;
            // Otherwise, keep going...
          }

@@ -411,13 +436,15 @@
                      "TAO (%P|%t) -
Leader_Follower[%d]::wait_for_event,"
                      " (leader) exit reactor event loop\n",
                      t_id));
-    }
-  }
+    } // End Scope #6: we should now hold the lock again
    //
    // End artificial scope for auto_ptr like helpers calling:
-  // this->reset_client_thread () and (maybe)
    // this->reset_client_leader_thread ().
    //
+  } // End Scope #5: we are no longer a client-leader
+  // We only get here if we were the client leader and either our
+  // event completed or an event loop thread has become available to
+  // become leader.

    // Wake up the next leader, we cannot do that in handle_input,
    // because the woken up thread would try to get into handle_events,
@@ -433,6 +460,26 @@
                         t_id),
                        -1);

+  // Yield to any event loop threads that may be waiting to take
+  // leadership - otherwise we will just loop around and take
+  // leadership again (because we hold the lock).
+  if (this->event_loop_threads_waiting_)
+  {
+    ACE_GUARD_RETURN (ACE_Reverse_Lock<TAO_SYNCH_MUTEX>, rev_mon,
+                      this->reverse_lock (), -1);
+    ACE_OS::thr_yield ();
+  }
+
+  } // End Scope #2: we loop here if our event is incomplete
+
+  //
+  // End artificial scope for auto_ptr like helpers calling:
+  // this->reset_client_thread ()
+  //
+
+  // We should only get here when our event is complete or timed-out
+  } // End Scope #1: we are no longer a client thread
+
    if (result == -1)
      ACE_ERROR_RETURN ((LM_ERROR,
                         "TAO (%P|%t) -
Leader_Follower[%d]::wait_for_event,"




> -----Original Message-----
> From: tao-bugs-bounces@... [mailto:tao-bugs-
> bounces@...] On Behalf Of
David.Kinder@...
> Sent: Thursday, November 19, 2009 10:55 AM
> To: tao-bugs@...
> Subject: [tao-bugs] Multi-threaded CORBA application can be
> deadlockedinside TAO
>
>     TAO VERSION: 1.7.4
>     ACE VERSION: 5.7.4
>
>     HOST MACHINE and OPERATING SYSTEM:
> Windows XP SP3
>
>     THE $ACE_ROOT/ace/config.h FILE:
> config-win32.h
>
>     BUILD METHOD USED:
> Microsoft Visual Studio 2005, TAO_ACE_vc8.sln
>
>     AREA/CLASS/EXAMPLE AFFECTED:
> Fault seems to be a logic problem inside TAO
>
>     DOES THE PROBLEM AFFECT:
>         COMPILATION? No
>         LINKING? No
>         EXECUTION? Yes, causes deadlock with TAO and application
>         OTHER (please specify)? No
>
>     SYNOPSIS:
> On a large client/server production system, a deadlock has been seen.
> The
> result of the deadlock is that there are threads that have called
> ORB::run()
> waiting on a lock, but no thread is actually doing anything to process
> incoming CORBA events.
>
>     DESCRIPTION:
> Our server architecture has a pool of CORBA worker threads, each of
> which
> calls ORB::run() to process incoming events (that is, CORBA calls from
> client applications). There also exist other threads in the server
that
> perform various tasks, which sometimes involve calling out to other,
> remote
> CORBA objects.
>
> Analysis of the deadlocked server shows that the sequence of events is
> as
> follows:
>
> 1) Client applications make sufficiently many CORBA calls to the
server
> that
> all the CORBA worker threads are busy handling the calls.
>
> 2) A thread (not one of the CORBA worker threads) makes a call to an
> external
> CORBA object.
>
> 3) While the above call is in progress, another application makes a
> CORBA call
> to the server. Normally, this would be handled by one of the CORBA
> worker
> threads. However, as described in 1), these are all busy. Therefore,
> the
> incoming event is handled by the thread in 2) that is waiting for the
> result
> of a call.
>
> 4) The thread in 2) dispatches the event to the appropriate servant,
> leading
> to a long-lived call to code inside the server that performs some
work.
>
> 5) Some of the CORBA threads in 1) complete the dispatching of the
> CORBA
> calls they were handling.
>
> 6) A further CORBA call from a client occurs. However, this is handled
> neither
> by the thread in 2) (since this is handling the upcall) nor any of the
> CORBA
> worker threads, which are all stuck in
> TAO_Leader_Follower::wait_for_client_leader_to_complete(), waiting for
> an event
> to be signalled, so the event is not handled.
>
> The problem seems to be that, once the thread in 2) has become the
> leader, no
> other thread can get into the reactor. Since the leader thread is
> handling a
> long-lived upcall, no other CORBA events can be processed until it
> returns.
> This can be a long time. In fact, in the actual system, this can be
> forever,
> as this upcall can end up depending on other CORBA calls which can now
> never
> be completed.
>
> Intuitively, this seems wrong. Once a thread is off handling an event,
> it
> surely should not be the leader any more? Ideally it would allow other
> threads
> to enter the reactor and handle further events.
>
>     REPEAT BY:
>
> The problem in the production system has been reduced to a relatively
> simple
> test case, the source code for which is attached. To reproduce, build
> the
> supplied source files to produce "server" and "client" executables,
> then
>
> 1) Run the server executable. This will wait for 10 seconds, waiting
> for
> a CORBA call from the client executable.
>
> 2) Run the client executable. This will call the server via the CORBA
> method
> Test2.call(), passing in a CORBA object it has instantiated.
>
> 3) The server immediately calls back to the client via Test1.call1().
>
> 4) Since (at this point) in the client application there is only one
> thread
> in the ORB (the main thread) this will handle the incoming call back
> from
> the server. This ends up in TestClient_i::call1(), which starts a pool
> of
> CORBA worker threads and then goes to sleep forever.
>
> 5) After 10 seconds, the server starts making repeated calls to the
> Test1.call2() CORBA method of the client. The first of these calls
> simply
> causes the system to hang: the client does not process the call.
>
> 6) If the final sleep() in TestClient_i::call1() is commented out, the
> system behaves as expected: repeated calls from the server to the
> client
> are
> seen. However, it seems to me that the system should work in any case:
> there
> are plenty of threads waiting to do work in the test client: it's just
> that
> none of them can get into the reactor.
>
> Does anyone have any ideas about this? Are we doing something foolish
> that
> we've not spotted? We have experimented with "-ORBWaitStrategy
> MT_NOUPCALL"
> without success, though looking at the code for that, we cannot see
how
> it
> could be expected to work at all.
>
> David Kinder
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

TAO VERSION: 1.7.4
     ACE VERSION: 5.7.4

     HOST MACHINE and OPERATING SYSTEM:
Windows XP SP3

     THE $ACE_ROOT/ace/config.h FILE:
config-win32.h

     BUILD METHOD USED:
Microsoft Visual Studio 2005, TAO_ACE_vc8.sln

     AREA/CLASS/EXAMPLE AFFECTED:
Fault seems to be a logic problem inside TAO

     DOES THE PROBLEM AFFECT:
         COMPILATION? No
         LINKING? No
         EXECUTION? Yes, causes deadlock with TAO and application
         OTHER (please specify)? No

     SYNOPSIS:
On a large client/server production system, a deadlock has been seen.
The
result of the deadlock is that there are threads that have called
ORB::run()
waiting on a lock, but no thread is actually doing anything to process
incoming CORBA events.

     DESCRIPTION:
Our server architecture has a pool of CORBA worker threads, each of
which
calls ORB::run() to process incoming events (that is, CORBA calls from
client applications). There also exist other threads in the server that
perform various tasks, which sometimes involve calling out to other,
remote
CORBA objects.

Analysis of the deadlocked server shows that the sequence of events is
as
follows:

1) Client applications make sufficiently many CORBA calls to the server
that
all the CORBA worker threads are busy handling the calls.

2) A thread (not one of the CORBA worker threads) makes a call to an
external
CORBA object.

3) While the above call is in progress, another application makes a
CORBA call
to the server. Normally, this would be handled by one of the CORBA
worker
threads. However, as described in 1), these are all busy. Therefore, the
incoming event is handled by the thread in 2) that is waiting for the
result
of a call.

4) The thread in 2) dispatches the event to the appropriate servant,
leading
to a long-lived call to code inside the server that performs some work.

5) Some of the CORBA threads in 1) complete the dispatching of the CORBA
calls they were handling.

6) A further CORBA call from a client occurs. However, this is handled
neither
by the thread in 2) (since this is handling the upcall) nor any of the
CORBA
worker threads, which are all stuck in
TAO_Leader_Follower::wait_for_client_leader_to_complete(), waiting for
an event
to be signalled, so the event is not handled.

The problem seems to be that, once the thread in 2) has become the
leader, no
other thread can get into the reactor. Since the leader thread is
handling a
long-lived upcall, no other CORBA events can be processed until it
returns.
This can be a long time. In fact, in the actual system, this can be
forever,
as this upcall can end up depending on other CORBA calls which can now
never
be completed.

Intuitively, this seems wrong. Once a thread is off handling an event,
it
surely should not be the leader any more? Ideally it would allow other
threads
to enter the reactor and handle further events.

     REPEAT BY:

The problem in the production system has been reduced to a relatively
simple
test case, the source code for which is attached. To reproduce, build
the
supplied source files to produce "server" and "client" executables, then

1) Run the server executable. This will wait for 10 seconds, waiting for
a CORBA call from the client executable.

2) Run the client executable. This will call the server via the CORBA
method
Test2.call(), passing in a CORBA object it has instantiated.

3) The server immediately calls back to the client via Test1.call1().

4) Since (at this point) in the client application there is only one
thread
in the ORB (the main thread) this will handle the incoming call back
from
the server. This ends up in TestClient_i::call1(), which starts a pool
of
CORBA worker threads and then goes to sleep forever.

5) After 10 seconds, the server starts making repeated calls to the
Test1.call2() CORBA method of the client. The first of these calls
simply
causes the system to hang: the client does not process the call.

6) If the final sleep() in TestClient_i::call1() is commented out, the
system behaves as expected: repeated calls from the server to the client
are
seen. However, it seems to me that the system should work in any case:
there
are plenty of threads waiting to do work in the test client: it's just
that
none of them can get into the reactor.

Does anyone have any ideas about this? Are we doing something foolish
that
we've not spotted? We have experimented with "-ORBWaitStrategy
MT_NOUPCALL"
without success, though looking at the code for that, we cannot see how
it
could be expected to work at all.

David Kinder

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi,

> >     SYNOPSIS: The sync scope policy flags set in the user application
> >               do not match the values as shown by the wireshark bus
> monitor
>
> I took a look at the GIOP 1.2 code and you're right that something odd
> is going on.  Johnny, it looks like you modified the values on August
> 19th, 2005 as part of the Any refactoring.  Can you please take a look
> and see how to fix the values so they are consistent with what's in the
> spec.  Also, should the SYNC_WITH_TRANSPORT have the value of 1 in the
> comments?

I only changed the methods call, not the values itself. Johannes, can you
store this in bugzilla, at this moment I don't have time to check this.

Johnny

>
> Thanks,
>
>         Doug
>
> >     DESCRIPTION: The value SYNC_WITH_SERVER(2) has the value (1) on
> the bus.
> >                  The value SYNC_WITH_TRANSPORT(1) has the value (0)
> on the bus.
> >                  The other policy values are mapped correctly.
> >
> >                  Please see
> TAO\tao\GIOP_Message_Generator_Parser_12.cpp the
> >                  values in the comments and values set differ as
> well. On the
> >                  receiving side, the values from the bus seem to be
> used
> >                  without any further mapping - thus a difference to
> what the
> >                  user wanted.
> >
> >                  This may have resulted from using the Ethereal bus
> monitor
> >                  at the time of implementation. Please check the
> following link:
> >
> >                  http://www.ethereal.com/lists/ethereal-
> users/200303/msg00122.html
> >
> >                  My goal is to use SYNC_WITH_TRANSPORT, but when I
> set the value
> >                  it gave me the behaviour of SYNC_NONE.
> >
> >     REPEAT BY:
> >
> >     SAMPLE FIX/WORKAROUND:
> >
> > Johannes Mulder, Fraunhofer IITB
> >
> > Simulation und Training
> >
> > Fraunhoferstr. 1, 76131 Karlsruhe, Germany
> >
> > Telefon : +49-721-6091 471
> >
> > mailto:Johannes.Mulder@...
> >
> > www.iitb.fraunhofer.de/
> >
> > _______________________________________________
> > tao-bugs mailing list
> > tao-bugs@...
> > http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

[Johnny, there's a question for you below.]

Hi Johannes,

    Thanks very much for using the PRF!

>     TAO VERSION: 1.6.5
>
>     ACE VERSION: 5.6.5
>
>     HOST MACHINE and OPERATING SYSTEM:
>
>         Intel(R) Core(TM)2 CPU
>
>         6400 @ 2.13GHz 3.00 GB RAM
>
>         Microsoft Windows XP Service Pack 3
>
>         Winsock 2.0
>
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>
>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
>
>     Visual Studio 2005 C++ (VC8.0)
>
>     THE $ACE_ROOT/ace/config.h FILE:
>
>     ace/config-win32.h
>
>     THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:
>
>     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>
>     AREA/CLASS/EXAMPLE AFFECTED:
>
>     DOES THE PROBLEM AFFECT:
>
>         COMPILATION? NO
>
>         LINKING? NO
>
>         EXECUTION? YES
>
>         OTHER (please specify)? NO
>
>     SYNOPSIS: The sync scope policy flags set in the user application
>               do not match the values as shown by the wireshark bus monitor

I took a look at the GIOP 1.2 code and you're right that something odd
is going on.  Johnny, it looks like you modified the values on August
19th, 2005 as part of the Any refactoring.  Can you please take a look
and see how to fix the values so they are consistent with what's in the
spec.  Also, should the SYNC_WITH_TRANSPORT have the value of 1 in the
comments?

Thanks,

         Doug

>     DESCRIPTION: The value SYNC_WITH_SERVER(2) has the value (1) on the bus.
>                  The value SYNC_WITH_TRANSPORT(1) has the value (0) on the
bus.
>                  The other policy values are mapped correctly.
>
>                  Please see TAO\tao\GIOP_Message_Generator_Parser_12.cpp the
>                  values in the comments and values set differ as well. On the
>                  receiving side, the values from the bus seem to be used
>                  without any further mapping Ð thus a difference to what the
>                  user wanted.
>
>                  This may have resulted from using the Ethereal bus monitor
>                  at the time of implementation. Please check the following
link:
>
>                 
http://www.ethereal.com/lists/ethereal-users/200303/msg00122.html
>
>                  My goal is to use SYNC_WITH_TRANSPORT, but when I set the
value
>                  it gave me the behaviour of SYNC_NONE.
>
>     REPEAT BY:
>
>     SAMPLE FIX/WORKAROUND:
>
> Johannes Mulder, Fraunhofer IITB
>
> Simulation und Training
>
> Fraunhoferstr. 1, 76131 Karlsruhe, Germany
>
> Telefon : +49-721-6091 471
>
> mailto:Johannes.Mulder@...
>
> www.iitb.fraunhofer.de/
>
> _______________________________________________
> tao-bugs mailing list
> tao-bugs@...
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi,

A lot of things related to the transport cache has been changed somewhere around
TAO 1.6.8, I would recommend you to try 1.7.2 or wait a day for the upcoming
1.7.3

Johnny

>  TAO VERSION: 1.6.2
>    ACE VERSION: 5.6.2
>
>    HOST MACHINE and OPERATING SYSTEM: Sun Solaris Sparc 10
>
>    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>    COMPILER NAME AND VERSION (AND PATCHLEVEL):
>
>    THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>    specific file, simply state which one]: Sun Solaris 10
>
>    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
>    C++)]: Sun Solaris 10
>
>    BUILD METHOD USED: traditional makefile/project file
> [experimental ./configure or traditional makefile/project file?]
>
>    CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>    (used by MPC when you generate your own makefiles): The default file
>
>    AREA/CLASS/EXAMPLE AFFECTED: No failure on compilation. If tansport
> [What example failed?  What module failed to compile?]
>
>    DOES THE PROBLEM AFFECT:
>        COMPILATION? NO
>            If so, what do your $ACE_ROOT/ace/config.h and
>            $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?
>        LINKING? NO
>            On Unix systems, did you run make realclean first?
>        EXECUTION? YES
>        OTHER (please specify)?
> [Please indicate whether ACE/TAO, your application, or both are
> affected.]
> My application is affected.
>
>    SYNOPSIS:
> [Brief description of the problem]
> If transport for IIOP is removed from transport cache at the server
> side, the client side is not aware of this, and when the client makes
> a CORBA call it receives COMM_FAILURE SystemException. The client
> should not receive COMM_FAILURE when server side transport caching is
> in effect. Is there a recycling strategy of some kind at the client
> side to actually close connections whose server side transport is
> already closed before making the actual use of the transport?
>
>    DESCRIPTION:
> [Detailed description of problem.  Don't just say "<blah>
> doesn't work, here's a fix," explain what your program does
> to get to the <blah> state. ]
> If transport for IIOP is removed from transport cache at the server
> side, the client side is not aware of this, and when the client makes
> a CORBA call it receives COMM_FAILURE SystemException. The client
> should not receive COMM_FAILURE when server side transport caching is
> in effect. Is there a recycling strategy of some kind at the client
> side to actually close connections whose server side transport is
> already closed before making the actual use of the transport?
>
>
>    REPEAT BY:
> [What you did to get the error; include test program or session
> transcript if at all possible.  ]
>
> Set the -ORBConnectionCacheMax to 1 while starting the server (e.g.
> may use TAO / tests / Cache_Growth_Test ).  Start a client and make a
> call to server and let the client wait for user input to make a second
> corba call to the server. Meanwhile start a second client program and
> let it make a call to the same server, this will force the server
> remove the transport to the fırst client from the cache and detroy it.
> At this point, let the first client continue and make the second call
> to the same server and observe that it receives a COMM_FAILURE.
>
>    SAMPLE FIX/WORKAROUND:
> [If available ]
> While getting a connection for a CORBA call it should do a check for
> connection health in some fashion.
> _______________________________________________
> tao-bugs mailing list
> tao-bugs@...
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi,

Thanks for using the PRF.

> TAO VERSION: 1.6.2
>   ACE VERSION: 5.6.2

You are using an old version of ACE+TAO.  A lot has changed in the
client side transport cache since then.  Please upgrade to
ACE+TAO+CIAO x.7.2 (i.e., ACE 5.7.2, TAO 1.7.2, and CIAO 0.7.2), which
you can download from

http://download.dre.vanderbilt.edu

under the heading: "Latest Micro Release Kit."

The DOC groups at Washington University, UC Irvine, and Vanderbilt
University only provide "best effort" support for non-sponsors for the
latest release, as described in

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html

Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out

http://www.dre.vanderbilt.edu/support.html

for a list of companies that will provide you with ACE+TAO commercial
support.

Thanks,

         Doug


>   HOST MACHINE and OPERATING SYSTEM: Sun Solaris Sparc 10
>
>   TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>   COMPILER NAME AND VERSION (AND PATCHLEVEL):
>
>   THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>   specific file, simply state which one]: Sun Solaris 10
>
>   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
>   C++)]: Sun Solaris 10
>
>   BUILD METHOD USED: traditional makefile/project file
>[experimental ./configure or traditional makefile/project file?]
>
>   CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>   (used by MPC when you generate your own makefiles): The default file
>
>   AREA/CLASS/EXAMPLE AFFECTED: No failure on compilation. If tansport
>[What example failed?  What module failed to compile?]
>
>   DOES THE PROBLEM AFFECT:
>       COMPILATION? NO
>           If so, what do your $ACE_ROOT/ace/config.h and
>           $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?
>       LINKING? NO
>           On Unix systems, did you run make realclean first?
>       EXECUTION? YES
>       OTHER (please specify)?
>[Please indicate whether ACE/TAO, your application, or both are affected.]
>My application is affected.
>
>   SYNOPSIS:
>[Brief description of the problem]
>If transport for IIOP is removed from transport cache at the server
>side, the client side is not aware of this, and when the client makes
>a CORBA call it receives COMM_FAILURE SystemException. The client
>should not receive COMM_FAILURE when server side transport caching is
>in effect. Is there a recycling strategy of some kind at the client
>side to actually close connections whose server side transport is
>already closed before making the actual use of the transport?
>
>   DESCRIPTION:
>[Detailed description of problem.  Don't just say "<blah>
>doesn't work, here's a fix," explain what your program does
>to get to the <blah> state. ]
>If transport for IIOP is removed from transport cache at the server
>side, the client side is not aware of this, and when the client makes
>a CORBA call it receives COMM_FAILURE SystemException. The client
>should not receive COMM_FAILURE when server side transport caching is
>in effect. Is there a recycling strategy of some kind at the client
>side to actually close connections whose server side transport is
>already closed before making the actual use of the transport?
>
>
>   REPEAT BY:
>[What you did to get the error; include test program or session
>transcript if at all possible.  ]
>
>Set the -ORBConnectionCacheMax to 1 while starting the server (e.g.
>may use TAO / tests / Cache_Growth_Test ).  Start a client and make a
>call to server and let the client wait for user input to make a second
>corba call to the server. Meanwhile start a second client program and
>let it make a call to the same server, this will force the server
>remove the transport to the f=C4=B1rst client from the cache and detroy it.
>At this point, let the first client continue and make the second call
>to the same server and observe that it receives a COMM_FAILURE.
>
>   SAMPLE FIX/WORKAROUND:
>[If available ]
>While getting a connection for a CORBA call it should do a check for
>connection health in some fashion.


--
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Vanderbilt University                        WEB:
www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203                          NET: d.schmidt@...
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

TAO VERSION: 1.6.2
    ACE VERSION: 5.6.2

    HOST MACHINE and OPERATING SYSTEM: Sun Solaris Sparc 10

    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
    COMPILER NAME AND VERSION (AND PATCHLEVEL):

    THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
    specific file, simply state which one]: Sun Solaris 10

    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
    C++)]: Sun Solaris 10

    BUILD METHOD USED: traditional makefile/project file
[experimental ./configure or traditional makefile/project file?]

    CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
    (used by MPC when you generate your own makefiles): The default file

    AREA/CLASS/EXAMPLE AFFECTED: No failure on compilation. If tansport
[What example failed?  What module failed to compile?]

    DOES THE PROBLEM AFFECT:
        COMPILATION? NO
            If so, what do your $ACE_ROOT/ace/config.h and
            $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?
        LINKING? NO
            On Unix systems, did you run make realclean first?
        EXECUTION? YES
        OTHER (please specify)?
[Please indicate whether ACE/TAO, your application, or both are affected.]
My application is affected.

    SYNOPSIS:
[Brief description of the problem]
If transport for IIOP is removed from transport cache at the server
side, the client side is not aware of this, and when the client makes
a CORBA call it receives COMM_FAILURE SystemException. The client
should not receive COMM_FAILURE when server side transport caching is
in effect. Is there a recycling strategy of some kind at the client
side to actually close connections whose server side transport is
already closed before making the actual use of the transport?

    DESCRIPTION:
[Detailed description of problem.  Don't just say "<blah>
doesn't work, here's a fix," explain what your program does
to get to the <blah> state. ]
If transport for IIOP is removed from transport cache at the server
side, the client side is not aware of this, and when the client makes
a CORBA call it receives COMM_FAILURE SystemException. The client
should not receive COMM_FAILURE when server side transport caching is
in effect. Is there a recycling strategy of some kind at the client
side to actually close connections whose server side transport is
already closed before making the actual use of the transport?


    REPEAT BY:
[What you did to get the error; include test program or session
transcript if at all possible.  ]

Set the -ORBConnectionCacheMax to 1 while starting the server (e.g.
may use TAO / tests / Cache_Growth_Test ).  Start a client and make a
call to server and let the client wait for user input to make a second
corba call to the server. Meanwhile start a second client program and
let it make a call to the same server, this will force the server
remove the transport to the fırst client from the cache and detroy it.
At this point, let the first client continue and make the second call
to the same server and observe that it receives a COMM_FAILURE.

    SAMPLE FIX/WORKAROUND:
[If available ]
While getting a connection for a CORBA call it should do a check for
connection health in some fashion.
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi,

Can you put this in bugzilla?

Johnny

>     TAO VERSION: 1.7.1
>     ACE VERSION: 5.7.1
>
>     HOST MACHINE and OPERATING SYSTEM:
>         AMD Opteron (64-bit x86), RedHat Enterprise Linux 5U3
>
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
>         g++ 4.3
>
>
>     THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>     specific file, simply state which one]:
>         #ifndef ACE_HAS_NO_THROW_SPEC
>         #define ACE_HAS_NO_THROW_SPEC
>         #endif
>         #include "ace/config-linux.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
>     C++)]:
>         exceptions=1
>         buildbits=64
>         ami=1
>         corba_messaging=1
>         shared_libs_only=1
>         include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU
>
>     BUILD METHOD USED:
>         Both.
>
>     CONTENTS OF
> $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>         N/A
>
>     AREA/CLASS/EXAMPLE AFFECTED:
>         N/A
>
>     DOES THE PROBLEM AFFECT:
>         COMPILATION?  No
>         LINKING?  No
>         EXECUTION?  Yes.  Application affected.
>
>     SYNOPSIS:
> I'm attempting to use two ORBs, one a Server ORB, one a Client ORB.  I
> activate a reply handler in the Server ORB, and make an AMI call on a
> remote object (which was demarshalled from an IOR using the Client
> ORB).  The replies are never received, apparently because the replies
> are being handled by the Client ORB instead of the Server ORB.  This
> seems incorrect, as the reply handler is supposed to be able to exist
> in a different context from the client.
>
>     DESCRIPTION:
> I'm trying to use the "Two ORB" strategy from the TAO FAQ to avoid
> nested upcalls (see
> http://www.theaceorb.com/faq/index.html#prevent_via_t_orb).  (I can't
> use the RW wait strategy because I need to use AMI.)  I'm only calling
> perform_work on the server orb, because the client ORB is never
> supposed to have any servants registered with it, so there should be
> nothing to do.  I expect if I called perform_work on the client ORB
> also that the calls would be handled there, so that might be a
> workaround for me.  However, if the replies are only ever handled by
> the client ORB, then I'm still opening myself up to nested upcalls
> (although they are more rare for AMI invocations than otherwise, they
> can still happen).  Nested upcalls are exactly what I was trying to
> avoid.
>
> In theory I should be able to have my reply handler exist in an
> entirely different process.  I'm not sure why I can't use it in another
> ORB in the same process.  Maybe I'm mistaken, but that seems incorrect.
>
>     REPEAT BY:
> I edited $TAO_ROOT/tests/AMI/client.cpp to use two ORBs, and it
> reproduces the problem.  Basically, it never receives its replies so
> gets stuck waiting.  I've attached two_orb_client.cpp, which is my
> modified version of client.cpp.
>
>     SAMPLE FIX/WORKAROUND:
> I think I can make the calls happen by calling perform_work on the
> Client ORB, but I think I'll be stuck worrying about nested upcalls.
>
> David Michael
> Senior Member of the Technical Staff
> Org 05521
> Sandia National Laboratories
> (505) 845-9113


_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

TAO VERSION: 1.7.1
     ACE VERSION: 5.7.1

     HOST MACHINE and OPERATING SYSTEM:
         AMD Opteron (64-bit x86), RedHat Enterprise Linux 5U3

     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
     COMPILER NAME AND VERSION (AND PATCHLEVEL):
         g++ 4.3


     THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
     specific file, simply state which one]:
         #ifndef ACE_HAS_NO_THROW_SPEC
         #define ACE_HAS_NO_THROW_SPEC
         #endif
         #include "ace/config-linux.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
     C++)]:
         exceptions=1
         buildbits=64
         ami=1
         corba_messaging=1
         shared_libs_only=1
         include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU

     BUILD METHOD USED:
         Both.

     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
         N/A

     AREA/CLASS/EXAMPLE AFFECTED:
         N/A

     DOES THE PROBLEM AFFECT:
         COMPILATION?  No
         LINKING?  No
         EXECUTION?  Yes.  Application affected.

     SYNOPSIS:
I'm attempting to use two ORBs, one a Server ORB, one a Client ORB.  I activate
a reply handler in the Server ORB, and make an AMI call on a remote object
(which was demarshalled from an IOR using the Client ORB).  The replies are
never received, apparently because the replies are being handled by the Client
ORB instead of the Server ORB.  This seems incorrect, as the reply handler is
supposed to be able to exist in a different context from the client.

     DESCRIPTION:
I'm trying to use the "Two ORB" strategy from the TAO FAQ to avoid nested
upcalls (see http://www.theaceorb.com/faq/index.html#prevent_via_t_orb).  (I
can't use the RW wait strategy because I need to use AMI.)  I'm only calling
perform_work on the server orb, because the client ORB is never supposed to have
any servants registered with it, so there should be nothing to do.  I expect if
I called perform_work on the client ORB also that the calls would be handled
there, so that might be a workaround for me.  However, if the replies are only
ever handled by the client ORB, then I'm still opening myself up to nested
upcalls (although they are more rare for AMI invocations than otherwise, they
can still happen).  Nested upcalls are exactly what I was trying to avoid.

In theory I should be able to have my reply handler exist in an entirely
different process.  I'm not sure why I can't use it in another ORB in the same
process.  Maybe I'm mistaken, but that seems incorrect.

     REPEAT BY:
I edited $TAO_ROOT/tests/AMI/client.cpp to use two ORBs, and it reproduces the
problem.  Basically, it never receives its replies so gets stuck waiting.  I've
attached two_orb_client.cpp, which is my modified version of client.cpp.

     SAMPLE FIX/WORKAROUND:
I think I can make the calls happen by calling perform_work on the Client ORB,
but I think I'll be stuck worrying about nested upcalls.

David Michael
Senior Member of the Technical Staff
Org 05521
Sandia National Laboratories
(505) 845-9113

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi Johannes,

> Thanks for your reply.

You are quite welcome - please make sure to send all emails about TAO to
the TAO mailing lists rather than to me directly.

> In the meantime I have found out what is happening in the server.
> When the server hangs, ACE is calling WSAIoctl (line 688 in
> ace\Sock_Connect.cpp) this call seems to be blocked, since this is a
> system call it explains why Cntl-C is not effective.

This looks like a problem with the Windows device driver.

> I do not know which system resource released when
> orb->resolve_initial_references ("RootPOA") is called. Another effect
> is when a USB flash drive is inserted or when the OK is pressed for
> safe removal of the USB flash drive the server process is also
> unblocked.  USB has no direct connection to ACE/TAO, thus it cannot be
> a direct ACE/TAO problem.

Right, it looks like a Windows device driver problem.

> I have four IDL operations which either send or get CORBA object
> references, once these four calls are finished WSAIoctl is not called
> again by ACE in the process. If the server is blocked, it is always
> calling one of these four operations. Do you know if there is a
> connection between using CORBA object references in an IDL operation
> and WSAIoctl? In some of the calls new CORBA objects are created on
> demand. Do you think changing my IDL operations to no longer transfer
> CORBA object references directly, but to use naming service instead
> would make a difference?

I'm not sure - this looks like a very system/context specific problem!

Doug
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi Johannes,

    Thanks for using the PRF.  It's going to be very hard to debug this
based on the info you provided since it sounds like the confluence of a
bunch of run-time network/OS/middleware/application issues.  I recommend
you check out

http://www.dre.vanderbilt.edu/support.html

for a list of companies that will provide you with TAO commercial
support on this stuff.

Thanks,

         Doug

>     TAO VERSION: 1.7
>
>     ACE VERSION: 5.7
>
>     HOST MACHINE and OPERATING SYSTEM:
>
>                 Dell XPS 730X Intel(R) Core(TM)i7 CPU     965 @ 3.20GHz (8
Processors)
>
>                 RAM 3.00 GB     64Bit Operating System
>
> Windows Vista(TM) Home Premium Service Pack 1
>
>                 Winsock 2.0
>
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>
>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
>
>                 Visual Studio 2005 C++ (VC8.0)
>
>     THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>
>     specific file, simply state which one]:
>
>                 "ace/config-win32.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
>
>     C++)]:
>
>     BUILD METHOD USED:
>
>  traditional project file
>
>     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>
>     (used by MPC when you generate your own makefiles):
>
>     AREA/CLASS/EXAMPLE AFFECTED:
>
> [What example failed?  What module failed to compile?]
>
>                 TAO server
>
>     DOES THE PROBLEM AFFECT:
>
>         COMPILATION? NO
>
>             If so, what do your $ACE_ROOT/ace/config.h and
>
>             $ACE_ROOT/include/makeinclude/platform_macros.GNU contain?
>
>         LINKING? NO
>
>             On Unix systems, did you run make realclean first?
>
>         EXECUTION? YES
>
>                     CORBA call is blocked intermittently
>
>         OTHER (please specify)? NO
>
> [Please indicate whether ACE/TAO, your application, or both are affected.]
>
>     SYNOPSIS:
>
>                 Once in about 100 program starts, an idl-operation getting an
object
>
>                 reference blocks.
>
>     DESCRIPTION:
>
>                 Once in about 100 program starts, an idl-operation getting an
object
>
>                 reference blocks. The server application in this case cannot
be killed
>
>                 with Cntl-C, The client application however can be killed with
Cntl-C.
>
>                 Using the Wireshark monitor, I could see that the GIOP message
for this
>
>                 operation had been sent to the server address, but the server
>
>                 implementation was not being called.
>
>                 A strange effect is that if another CORBA program (I´ll call
it ABC)
>
>                 is started on the server, the blocked server above immediately
>
>                 continues to perform from where it stopped and it can now be
>
>                 killed by Cntl-C.
>
>                 Using the debugger on ABC, I saw that it was only necessary to
call:
>
>                                orb = CORBA::ORB_init (argc_, argv_, name);
>
>  CORBA::Object_var obj = orb->resolve_initial_references ("RootPOA");
>
>                 to unblock the server. Stepping into
resolve_initial_references to get
>
>                 to the code which unblocks the server produces the following
stack trace:
>
>                 ACEd.dll!std::equal_to<unsigned int>::operator()(const
unsigned int & _Left=0, const unsigned int & _Right=
> 0)  Line 109               C++
>
> >             ACEd.dll!ACE_Array_Map<unsigned int,ACE_Service_Type const
*,std::equal_to<unsigned int> >::find(const
> unsigned int & k=0)  Line 236 + 0x10 bytes          C++
>
>                 ACEd.dll!ACE_Service_Repository::find_i(const char *
name=0x030bbd38, unsigned int & slot=0, const
> ACE_Service_Type * * srp=0x0017ef34, bool ignore_suspended=true)  Line 239 +
0xc bytes    C++
>
>                 ACEd.dll!ACE_Service_Repository::find(const char *
name=0x030bbd38, const ACE_Service_Type * * srp=
> 0x0017ef34, bool ignore_suspended=true)  Line 345 + 0x18 bytes C++
>
>                 ACEd.dll!ACE_Service_Gestalt::find(const char *
name=0x030bbd38, const ACE_Service_Type * * srp=0x0017ef34,
> bool ignore_suspended=true)  Line 65 + 0x17 bytes      C++
>
>                 ACEd.dll!ACE_Dynamic_Service_Base::find_i(const
ACE_Service_Gestalt * & repo=0x01ae87a8, const char * name=
> 0x030bbd38, bool no_global=false)  Line 50 + 0x1c bytes              C++
>
>                 ACEd.dll!ACE_Dynamic_Service_Base::instance(const
ACE_Service_Gestalt * repo=0x01ae87a8, const char * name=
> 0x030bbd38, bool no_global=false)  Line 73 + 0x11 bytes              C++
>
>                
TAOd.dll!ACE_Dynamic_Service<TAO_Adapter_Factory>::instance(const
ACE_Service_Gestalt * conf=0x01ae87a8,
> const char * name=0x030bbd38)  Line 46 + 0x12 bytes  C++
>
>                 TAOd.dll!TAO_ORB_Core::root_poa()  Line 1810 + 0x1e bytes  C++
>
>                 TAOd.dll!CORBA::ORB::resolve_initial_references(const char *
name=0x00ad7fe8, ACE_Time_Value * timeout=
> 0x00000000)  Line 873 + 0xf bytes        C++
>
>                 GeRtiD.exe!GERTICO::GeRtiOrb::GeRtiOrb(int argc=1, char * *
argv=0x030b7f58, GERTICOconf & conf={...}) 
> Line 98 + 0x15 bytes      C++
>
>                 GeRtiD.exe!mainServer::init()  Line 325 + 0x49 bytes    C++
>
>                 GeRtiD.exe!ace_main_i(int argc=1, char * * argv=0x03081400) 
Line 541 + 0x8 bytes     C++
>
>                 GeRtiD.exe!ACE_Main::run_i(int argc=1, char * *
argv=0x03081400)  Line 504 + 0x30 bytes       C++
>
>                 ACEd.dll!ACE_Main_Base::run(int argc=1, char * *
argv=0x03081400)  Line 88 + 0x17 bytes       C++
>
>                 GeRtiD.exe!main(int argc=1, char * * argv=0x03081400)  Line
504 + 0x5f bytes C++
>
>                 GeRtiD.exe!__tmainCRTStartup()  Line 586 + 0x19
bytes             C
>
>                 GeRtiD.exe!mainCRTStartup()  Line 403               C
>
>                 kernel32.dll!7638e3f3()               
>
>                 [Frames below may be incorrect and/or missing, no symbols
loaded for kernel32.dll] 
>
>                 ntdll.dll!7725cfed()        
>
>                 ntdll.dll!7725d1ff()        
>
>                 
GeRtiD.exe!std::_Tree<std::_Tmap_traits<std::basic_string<wchar_t,std::char_trai\
ts<wchar_t>,std::allocator
> <wchar_t> >,unsigned
long,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocato\
r<wchar_t> >
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,s\
td::allocator<wchar_t> > const ,unsigned
> long> >,0> >::const_iterator::_Inc()  Line 388 + 0xc bytes            C++
>
>                
GeRtiD.exe!GERTICO::GeRtiOwnershipMasterI::attributeOwnershipDivestitureIfWanted\
(unsigned int fedId=
> 3407924, unsigned int theObject=6488163, const GeRtiFactory::Handles &
theAttributes={...})  Line 801 + 0x6f
> bytes                C++
>
>                 Please note:
>
>                 Windows Vista is being used for the first time.
>
>                 The server application has been used for many years on
single-processor
>
>                 Windows XP and Linux SUSE 9.3 platforms.
>
> I have occasionally received reports by others that this server blocks
intermittently
>
> on multi-processor Windows XP and Linux SUSE 9.3 platforms, but I could not
>
> reproduce it at my site.
>
> I am not 100% sure that the object reference parameter is part of the problem,
but
>
> every time blocking occurred it was a get object reference operation.
>
>     REPEAT BY:
>
> [What you did to get the error; include test program or session
>
> transcript if at all possible.  ]
>
>     SAMPLE FIX/WORKAROUND:
>
> [If available ]
>
> Thank you in advance for any help you can provide.
>
> Johannes Mulder, Fraunhofer IITB
>
> Simulation und Training
>
> Fraunhoferstr. 1, 76131 Karlsruhe, Germany
>
> Telefon : +49-721-6091 471
>
> mailto:Johannes.Mulder@...
>
> www.iitb.fraunhofer.de/
>
> _______________________________________________
> tao-bugs mailing list
> tao-bugs@...
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hello!

I am sorry, the entry was added with this commit:

Thu Nov  8 02:09:02 UTC 2007  Phil Mesnier  <mesnier_p@...>

	 * ace/Codeset_Registry_db.cpp:
	   Added an entry for UTF-8.

--
Max Khon
Platform Team Leader
Parallels Automation
Parallels
E-mail: mkhon@...
Web Site: http://parallels.com/

> -----Original Message-----
> From: schmidt@... [mailto:schmidt@...]
> Sent: Thursday, April 30, 2009 7:06 PM
> To: Maxim Khon
> Cc: tao-bugs@...
> Subject: Re: [tao-bugs] UTF-8 is missing in Codeset registry db
>
>
> Hi Max,
>
> > The problem has already been raised on this list several years ago:
> >
> > http://www.archivum.info/comp.soft-sys.ace/2007-11/msg00099.html
> >
> > Can we add UTF-8 to the default codeset db?
>
> Can you please send us the patches for this?
>
> Thanks,
>
> Doug
>
> >
> > Max Khon
> >
> > Platform Team Leader
> >
> > Parallels Automation
> >
> > Parallels
> >
> > E-mail: mkhon@...
> >
> > Web Site: http://parallels.com/
> >
> > _______________________________________________
> > tao-bugs mailing list
> > tao-bugs@...
> > http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi Max,

> The problem has already been raised on this list several years ago:
>
> http://www.archivum.info/comp.soft-sys.ace/2007-11/msg00099.html
>
> Can we add UTF-8 to the default codeset db?

Can you please send us the patches for this?

Thanks,

Doug

>
> Max Khon
>
> Platform Team Leader
>
> Parallels Automation
>
> Parallels
>
> E-mail: mkhon@...
>
> Web Site: http://parallels.com/
>
> _______________________________________________
> tao-bugs mailing list
> tao-bugs@...
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

TAO VERSION: 1.6.9
      ACE VERSION: 5.6.9

      HOST MACHINE and OPERATING SYSTEM:

Linux lap2.bonsai.com 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23
23:08:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

      THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
      specific file, simply state which one]:

cp config-linux.h config.h
#define TAO_IDL_INCLUDE_DIR "/usr/include"
#define ACE_HAS_IPV6 // Ken Sedgwick 2006-06-14
#define ACE_USES_IPV4_IPV6_MIGRATION // Ken Sedgwick 2006-06-14
#define ACE_HAS_REACTOR_NOTIFICATION_QUEUE  // Ken Sedgwick 2006-04-19
#define ACE_GCC_HAS_TEMPLATE_INSTANTIATION_VISIBILITY_ATTRS 1  // Ken
Sedgwick 2007-05-05

      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
      C++)]:

ssl = 1
include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU
x11 = 1
xt = 1
tk = 1
fl = 1
qt = 1
gl = 1
ace_qtreactor = 1
ace_xtreactor = 1
ace_tkreactor = 1
ace_flreactor = 1
tao_qtresource = 1
tao_xtresource = 1
tao_tkresource = 1
tao_flresource = 1
buildbits = 64
# Enable Fedora optimization
OCFLAGS = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
OCCFLAGS = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic

      SYNOPSIS:

The tao_idl compiler as installed by the Fedora RPM (uses
TAO_INCLUDE_DIR instead of TAO_ROOT env variable) generates code
with missing include lines.

      DESCRIPTION:

The following IDL file exhibits the problem:
----------------------------------------------------------------
#include <orbsvcs/CosTradingRepos.idl>
#include <orbsvcs/CosTrading.idl>

interface FooBar  {

      void MethodA(in CosTrading::ServiceTypeName TypeName,
                   in
CosTradingRepos::ServiceTypeRepository::PropStructSeq Props,
                   in
CosTradingRepos::ServiceTypeRepository::ServiceTypeNameSeq Super_Types);

      void MethodB(in CosTrading::ServiceTypeName TypeName,
                   in CosTrading::PropertySeq Properties);

};
----------------------------------------------------------------

The generated code lacks the following includes:
----------------------------------------------------------------
......
#ifndef _TAO_IDL_FOOBARS_H_
#define _TAO_IDL_FOOBARS_H_


#include "FooBarC.h"
#include "orbsvcs/CosTradingReposS.h"     <= MISSING
#include "orbsvcs/CosTradingS.h"          <= MISSING

#if !defined (ACE_LACKS_PRAGMA_ONCE)
# pragma once
#endif /* ACE_LACKS_PRAGMA_ONCE */

#include "tao/Collocation_Proxy_Broker.h"
#include "tao/PortableServer/PortableServer.h"
#include "tao/PortableServer/Servant_Base.h"
.......
----------------------------------------------------------------

The problem is that the TAO_IDL_INCLUDE_DIR support needs to be
extended to some new code in :
    ACE_wrappers/TAO/TAO_IDL/driver/drv_mcpp_preproc.cpp
    ACE_wrappers/TAO/TAO_IDL/driver/drv_preproc.cpp

This is also filed in bugzilla:

      http://bugzilla.dre.vanderbilt.edu/show_bug.cgi?id=3661

      SAMPLE FIX/WORKAROUND:

The attached patch fixes the problem:

--
Ken Sedgwick
Bonsai Software, Inc.
http://www.bonsai.com/ken/
(510) 610-4162
ken+5a4@...
Public Key: http://www.bonsai.com/ken/ken.asc
GPG Fingerprint: 851E 3B07 E586 0843 9434  5CC7 4033 3B9B 3F3F 9640

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

here is the bug:

http://bugzilla.dre.vanderbilt.edu/show_bug.cgi?id=3637

It includes automated test.

Thanks, Milan.

Simon McQueen wrote:
> Hi Milan,
>
> I've done quite a few fixes to the FT client side in the past so I, for
> one, would be grateful if you would.
>
> Would there be any chance you could turn your test code into a full
> regression test, like the other ones for FT under
> $TAO_ROOT/orbsvcs/tests ? It would increase the likelihood that someone
> will be able to get around to looking into it quicker.
>
> On 30/03/2009 16:25, Milan Cvetkovic wrote:
>> Should I file this to bugzilla?
>>
>> Thanks, Milan.
>>
>> Milan Cvetkovic wrote:
>>>     TAO VERSION: 1.6.8
>>>     ACE VERSION: 5.6.8
>>>
>>>     HOST MACHINE and OPERATING SYSTEM:
>>>         Linux Debian 4.0 on x86
>>>
>>>     COMPILER NAME AND VERSION:
>>>         g++-4.1.2
>>>
>>>     THE $ACE_ROOT/ace/config.h FILE:
>>>         config-linux.h
>>>
>>>     THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:
>>>         platform-linux.h
>>>
>>>     AREA/CLASS/EXAMPLE AFFECTED:
>>>         orbsvcs/FaultTolerance
>>>
>>>     DOES THE PROBLEM AFFECT:
>>>         EXECUTION? YES
>>>
>>>     SYNOPSIS:
>>>         TAO_FT_ClientORB does not use second profile in comma
>>>         delimited corbaloc
>>>
>>>     DESCRIPTION:
>>>
>>> I have a two server processes serving the same corba object, and
>>> listening on ports 9220 and 9221.
>>>
>>> I supply the client with the corbaloc with comma delimited list of
>>> objects:
>>>
>>> corbaloc:iiop:localhost:9220,iiop:localhost:9221/CorbaSimple
>>>
>>> I run the client. It periodically invokes "hello()" on server, and it
>>> ends up being served by the server listening on port 9220.
>>>
>>> When I kill the server listening on port 9220, I expect client to
>>> connect to server on port 9221 and continue RPCs using that server.
>>>
>>> The problem: When TAO_FT_ClientORB is loaded, this does not work.
>>>
>>>
>>>     REPEAT BY:
>>> I have created small example which reproduces the problem (attached)
>>>
>>> 1) Run server on two ports: 9220 and 9221
>>>
>>> window1$ ./server -ORBEndPoint iiop://:9220
>>> window2$ ./server -ORBEndPoint iiop://:9221
>>>
>>> 2) Run client:
>>>
>>> window3$ echo \
>>> "corbaloc:iiop:localhost:9220,iiop:localhost:9221/CorbaSimple" \
>>> | ./client -ORBSvcConf client.conf -ORBDebug -ORBDebugLevel 10
>>>
>>> 3) client talks to 9220
>>> 4) kill the process running on 9220
>>> 5) client reports "CORBA::TRANSIENT" without ever trying to connect
>>>    to server on port 9221
>>>
>>> To remove TAO_FT_ClientORB, run the client process in step (2)
>>> without conf file:
>>>
>>> echo "corbaloc:iiop:localhost:9220,iiop:localhost:9221/CorbaSimple" \
>>> | ./client -ORBDebug -ORBDebugLevel 10
>>>
>>>
>>> In this case client reconnects to 9221
>>>
>>> Any help would be appreciated.
>>>
>>> Thanks, Milan.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> tao-bugs mailing list
>>> tao-bugs@...
>>> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs
>>
>
>

_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs

Hi Sumit,

Since you're using OCI's version of TAO I recommend sending your
questions to taosupport@... since they provide excellent
commercial support for their releases of TAO.  Naturally, we encourage
and appreciate other members of the ACE+TAO user community who can
respond to questions about the OCI release if they have the answers.

You may also want to consider upgrading to ACE+TAO+CIAO x.6.8 (i.e.,
ACE 5.6.8, TAO 1.6.8, and CIAO 0.6.8), which you can download from

http://download.dre.vanderbilt.edu

under the heading: "Latest Micro Release Kit".

The DOC groups at Washington University, UC Irvine, and Vanderbilt
University only provide "best effort" support for non-sponsors for the
latest release, as described in

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html

Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out

http://www.dre.vanderbilt.edu/support.html

for a list of companies that will provide you with ACE+TAO commercial
support.

Thanks,

         Doug


> TAO VERSION: 1.3a_P7
>     ACE VERSION: 1.3a_P7
>     HOST MACHINE: Solaris Sun-Fire-T200
>     OPERATING SYSTEM: Solaris 10
>     TARGET MACHINE and OPERATING SYSTEM: Same as Host
>     COMPILER NAME AND VERSION (AND PATCHLEVEL): CC: Sun C++ 5.9 SunOS_sparc
>     AREA/CLASS/EXAMPLE AFFECTED:
>     DOES THE PROBLEM AFFECT:
>         COMPILATION? Yes
>         LINKING? No
>         EXECUTION? No
>         OTHER (please specify)? NO
>     SYNOPSIS:
>     Alternative to get exception info after CORBA::Request invoke() method
being invoked    DESCRIPTION:
>     CORBA:: Request env() method is a deprecated method  and I am trying to
use request->env()->exception() on
> CORBA::Request Object "request" but its giving a compilation error saying "env
is not a member of CORBA_Request". Here is
> the code snippet:
>
> <Code>
> try {
>       req->invoke ();
>      }
>      catch (...) {
>      }
>      // Handle any exception that were thrown.
>      DOMDocument *resp_doc = NULL;
>
>      CORBA::Exception *pEx = req->env()->exception (); // This line giving
compilation error
>      if (pEx) {
>   CORBA::UnknownUserException *puex = CORBA::UnknownUserException::_downcast
(pEx);
>   CORBA::SystemException *psex = CORBA::SystemException::_downcast (pEx);
>   CORBA::Any tmp;
>   const char *exType= "UnknownException";
>   if (puex != NULL) {
>       DynamicAny::DynAny_var tmpDa = dynFact->create_dyn_any (puex->exception
());
>       resp_doc = NULL;
>       tmpDa->destroy ();
>       throw(resp_doc);
>   } else if (psex != NULL) {
>       tmp <<= *psex;
>       exType = "SystemException";
>   } else {
>       tmp <<= *pEx;
>   }
> </Code>
>
> Please provide me the alternative approach I can use to check for exception if
any after the call to CORBA::Request invoke
> () method above.
> Can you also provide me the information as to when this method env() was
deprecated i.e. in which version of TAO/ACE?
>
> Thanks in advance.
>
> Regards
> Sam
>
>
--------------------------------------------------------------------------------\
-------------------------------------------
> Add more friends to your messenger and enjoy! Invite them now..
>
> _______________________________________________
> tao-bugs mailing list
> tao-bugs@...
> http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs
_______________________________________________
tao-bugs mailing list
tao-bugs@...
http://list.isis.vanderbilt.edu/mailman/listinfo/tao-bugs