Home Help Center

Proxy hanging when a Glacier2::Session is renewed

denndenn Member Denn SporcicOrganization: L3 NautronixProject: Great Barrier Reef Vessel Tracking System
Hi Guys,

Running a simple client / server app with my PRIMARY AIM in this exercise is to handle network outages and recover from them in a well mannered way :)

Pieces are:

Client
GLACIER2
Server

Basically a simple client / server app using one proxy to talk to a server behind Glacier.
Standard stuff...

Client has 3 threads running in it.
- the main thread and
- 2 monitoring threads

Main thread does some work etc etc..

1st monitoring thread creates a Glacier2::Session on the glacier router. This is using simple password auth that returns a NULL proxy. (All well and good).
This thread also pings the Router periodically (using Glacier2::RouterPrx) to check network availablity as well as keeping the Session alive on the Router. (All well and good).
When any exceptions occur... be it Connection related or timeout releated the monitoring thread will detect this and create a new Session on the Router and start pinging periodically once again ( All well and good ). This thread works fine and works with random network outages, network cable yanking etc etc... Fairly robust.

2nd thread does a similar thing. This thread has a Proxy (created from a stringified represenation) that pings the server behind the router. Pings come back happily and all behaves correctly. :)

However a quirk I am running into is the behaviour of the Proxy, when a new Glacier2::Session is created in the 1st monitor thread. When a new Session is created the proxy in the 2nd monitor thread seems to hang on the next ping it attempts.

My test case is a simple one.

Start up server and glacier...(on one server) then client (running on a separate PC).

Client pings both Router and Server happily.
I pull out the network cable and let the 2 threads throw timeout and connection exceptions. This continues each loop as expected.
I plug the netwok cable back in and let the OS do its thing.
1st thread is able to renew a Glacier2::Session with the router and pings happily.

My issue is with the 2nd thread. When a new Session is established the Proxy hangs on the next time it wants to ping the server ?????

I'm not sure on how the proxy behaves when used through a router and its semantics when Sessions are recreated on the client. Am I missing something here ?

Help much appreciated :

Denn

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    It sounds like the same problem as the one mentioned on [thread=4642]this thread[/thread]. I recommend destroying/re-creating the communicator after each Glacier2 session (or eventually create/destroy on object adapter associated with the router). Let us know if you need more information on this.

    Cheers,
    Benoit.
  • denndenn Member Denn SporcicOrganization: L3 NautronixProject: Great Barrier Reef Vessel Tracking System
    Well that was definitely not the answer I was looking for *cringe. Will this bug be rectified anytime soon ?
    Recreating the communicator is not a good long term strategy in my opinion.

    Thanks for your help Benoit
    Denn
  • denndenn Member Denn SporcicOrganization: L3 NautronixProject: Great Barrier Reef Vessel Tracking System
    Thinking about it a little more....
    I'm inheriting from Ice::Application on the client side (to make things easier). Is there a way to reinitialise the communicator via the base class Ice::Application or set a new communicator instance for Ice::Application to manage ? ? I have read the code for class Ice::Application and have noticed that you declare a global static for the CommunicatorPtr. I am trying to find a Base class method to initialise a new Communicator ?



    Being able to call main
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    Ice::Application isn't intended to be used with multiple communicators so you shouldn't use it here if you choose to work-around this problem by re-creating the communicator. The other option is to instead create an object adapter associated with the router after establishing the session and destroy this object adapter when the session finishes.

    Ice 3.4 will provide a helper class that allows to easily re-create the Glacier2 session and communicator.

    Cheers,
    Benoit.
Sign In or Register to comment.