[Ace-users] Notification Service Network Disconnect

Foxhunter jack.gold at baesystems.com
Mon Feb 4 09:20:04 CST 2008


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 ]



More information about the Ace-users mailing list