[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