[Ace-users] [ace-users] Notification Service Network Disconnect
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Mon Feb 4 20:10:09 CST 2008
Hi Jack,
Since you're using OCI's version of TAO I recommend sending your
questions to taosupport at ociweb.com 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 (i.e., ACE
5.6, TAO 1.6, and CIAO 0.6), which you can download from
http://download.dre.vanderbilt.edu
under the heading: "Latest Beta 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
>Thanks for the fast response. I am concerned that this solution is
>tied to the Reactor as it seems to me the Notification Service is the
>lockup point. My server application is simply pushing data to the
>Notification Service which should, in my understanding, run through
>each of the registered clients and push data individually to each
>client. By disconnecting a client, the Notification Service appears
>to get stuck. So the reliability, I'm guessing, should be controlled
>in the Notification Service rather than my server application. In
>fact, attempting to resolve the problem in the server application
>would result in a race condition in the future between the disconnect
>and the push call.
>
>Also, this solution points to a disconnect on the server cable, not
>the client cable. In my case, I'm pulling the cable on the client.
>
>Below is the PRF I should have included earlier. My apologies for not
>understanding the protocol.
>
>--Jack
>
>This is ACE version 5.5a, released Thu Mar 1 16:45:29 UTC 2007.
>
>This is a modified version of the ACE originally released by the
>DOC group. It contains additional fixes and optimizations.
>An overview of OCI's version of ACE is available in the
>ACE_wrappers/OCIReleaseNotes.html file. Changes made for this
>patch can be found in the ACE_wrappers/OCIChangeLog file.
>Many of the the changes have been included in the current versions
>of ACE released by the DOC group.
>
>Since ACE is open source and free of licensing fees, we do not
>derive any revenue other than through our services and support
>(and a little from book and CD sales). So, unfortunately, we are
>unable to provide free support.
>
>For more details, and information on opening a support contract
>please see http://www.theaceorb.com/support/index.html or contact
>sales at ociweb.com .
>
>Other sources of information you may want to consider using are:
>
>OCI TAO 1.5a source code, release notes, and other downloads:
> http://www.theaceorb.com/downloads/#1.5a
>
>OCI TAO 1.5a CD's and 2-Volume Developer's Guide:
> http://www.theaceorb.com/buy
>
>OCI training courses:
> http://www.theaceorb.com/training
>
>OCI CORBA News Brief articles:
> http://www.ociweb.com/cnb/index.html
>
>ACE and TAO mailing lists:
> http://www.cs.wustl.edu/~schmidt/TAO-mail.html
>
>Thank you for your interest in ACE.
>-----------------------------------------------------------------------
>If you do not have a support contract with OCI, "best effort" support
>is
>available from other ACE and TAO users in the ACE/TAO mailing lists,
>which are described at http://www.cs.wustl.edu/~schmidt/ACE-mail.html.
>Please note, however, that this support is community based, i.e.,
>users help each other, so long and involved issues are less likely to
>be answered. The main objectives of these mailing lists are to
>resolve issues with the latest beta versions of ACE and TAO, and to
>share experiences with CORBA and ACE libraries in general. Thus,
>questions relating to earlier versions of ACE and TAO will not be
>answered by the open-source development team.
>
>An easy way to track and search for bug fixes or answers to general
>questions is to go to the "comp.soft-sys.ace" newsgroup (conveniently
>accessible via Google)
>at http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.soft-sys.ace
>Another news group, "comp.object.corba", is more generalized
>regarding the use of CORBA and is located at
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.object.corba.
>
>8<----------8<----------8<----------8<----------8<----------8<----------8<----
>
> ACE VERSION: 5.5a
>
> HOST MACHINE and OPERATING SYSTEM: Dell Precision 380
>
> TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> COMPILER NAME AND VERSION (AND PATCHLEVEL):
>
> CONTENTS OF $ACE_ROOT/ace/config.h [if you use a link to a
>platform-
> specific file, simply state which one]: config-linux.h
>
> CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU [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++)]:
>
> debug=0
> optimize=1
> inline=1
> shared_libs=1
> threads=1
> minimum_corba=0
> corba_messaging=1
> exceptions=1
> ACE_HAS_GNUG_PRE_2_8=0
> TAO_IDL=$(ACE_ROOT)/TAO/TAO_IDL/tao_idl
> TAO_IDL_PREPROCESSOR=g++
> TAO_ORBSVCS= Naming CosEvent Notify Trader
> include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU
>
> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/
>default.features
> (used by MPC when you generate your own makefiles):
>
> LEVEL OF URGENCY (LOW, MEDIUM, or HIGH):
>
> MEDIUM
>
> AREA/CLASS/EXAMPLE AFFECTED:
>[What example failed? What module failed to compile?]
>
> DOES THE PROBLEM AFFECT:
> COMPILATION?
> LINKING?
> On Unix systems, did you run make realclean first?
> EXECUTION?
> Execution seems to be the issue, but only when the Ethernet
>is disconnected.
>
> OTHER (please specify)?
>[Please indicate whether ACE, your application, or both are affected.]
>
> SYNOPSIS:
>[Brief description of the problem]
>
> Notification Service Network Disconnect causes hang in event
>dispatch.
>
> 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. ]
>
> I have a server running on Fedora Core Linux and
>two separate clients running on windows machines. The server
>application connects to the notification service and the clients
>receive dispatches. This all seems to work fine. At first, if I
>killed one of my client applications, the other application would stop
>receiving dispatches. When I implemented the QoS Timeout feature
>along with the ThreadPool and DispatchThreads, my secondary client
>continues to receive the dispatches as it should. Unfortunately, I
>noticed that if I disconnect the Ethernet cable to one of the clients,
>the client that is still connected, once again, stops receiving
>dispatches. If I reconnect the cable, it takes up to two minutes to
>begin receiving again. Is this a configuration problem with the
>notification service? or is there something in the underlying linux
>that I need to be looking at?
>
> I am almost certain this is a configuration issue and not a bug
>in ACE/TAO. I'm just not sure I configured the application and
>network
>correctly at this point.
>
> REPEAT BY:
>[What you did to get the error; include test program or session
>transcript if at all possible. ]
>
> Server application and two separate client applications running
> on individual Windows XP systems. The client applications are
> exactly the same application. The server simply outputs information
> periodically to registered clients. The clients print the events
> to the terminal when they arrive.
>
> SAMPLE FIX/WORKAROUND:
>[If available ]
>
--
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 at vanderbilt.edu
More information about the Ace-users
mailing list