Archived

This forum has been archived. Please start a new discussion on GitHub.

IceStorm unsubscribe intermittent delay

phil++
phil++
in Help Center
I have a nagging, intermittent problem with IceStorm and unsubscribe. Occasionally, unsubscribe hangs for approx. 5 minutes before finally issuing the network call to perform the unsubscribe. The IceStorm log below reveals the delay, but no other error. I wrapped the unsubscribe with console output so I could see when that function was entered and when it exited:
cerr << "entering usubscribe" << endl;
m_topicProxy->unsubscribe (m_subscriberProxy);
cerr << "exiting unsubscribe" << endl;

I can plainly see the "entering unsubscribe" as the delay begins. The "exiting unsubscribe" follows about 5 minutes later. The program exits normally. No other errors are present.

Any ideas what this might be?

Phil
1.2.3.4 is my local machine (ips changed to protect the innocent).
5.6.7.8 is the remote host running IceStorm with a topic manager 
listening on port 10000.  My adapter is listening on port 10005.

[ 08/22/08 01:26:02.252 icebox: Network: accepted tcp connection
  local address = 5.6.7.8:10000
  remote address = 1.2.3.4:52695 ]
[ 08/22/08 01:26:02.340 icebox: Topic: test topic 1: subscribeAndGetPublisher: test subscriber ]
[ 08/22/08 01:26:03.034 icebox: Network: tcp connection established
  local address = 5.6.7.8:50351
  remote address = 1.2.3.4:10005 ]
[ 08/22/08 01:28:02.131 icebox: Network: closing tcp connection
  local address = 5.6.7.8:10000
  remote address = 1.2.3.4:52695 ]

// unsubscribe() activated here at about 01:31, what follows below 
// is a delay of several minutes before the topic manager request is 
// issued to the remote IceStorm and a normal unsubscribe is processed.
// The log reveals only the time delay, no other errors.

[ 08/22/08 01:36:47.582 icebox: Network: accepted tcp connection
  local address = 5.6.7.8:10000
  remote address = 1.2.3.4:46369 ]
[ 08/22/08 01:36:47.611 icebox: Topic: test topic 1: unsubscribe: test subscriber ]
[ 08/22/08 01:36:47.647 icebox: Network: closing tcp connection
  local address = 5.6.7.8:10000
  remote address = 1.2.3.4:46369 ]
[ 08/22/08 01:36:47.648 icebox: Network: closing tcp connection
  local address = 5.6.7.8:50351
  remote address = 1.2.3.4:10005 ]

Comments

  • benoit
    benoit Rennes, France
    Hi Phil,

    Which Ice version and operation system are you using? The network tracing of the IceStorm server doesn't show anything obvious. Did you try enabling tracing on the client instead to see when the client was trying to establish the connection and if the client wasn't trying to connect to some bogus IP addresses first?

    Cheers,
    Benoit.
  • phil++
    phil++
    Benoit,

    Ice 3.3.0 on 32bit x86 Linux platforms.

    Your instincts were good. Tracing the client side, I saw that my client was trying to connect to the LAN address (192.168.x.y) of the remote IceStorm server, not the needed WAN address. After a few timeouts, the proxy eventually uses the WAN address and the unsubscribe proceeds.

    Adding additional configuration to the server-side topic manager adapter resolves the issue, BUT, doesn't this configuration dictate that the IceStorm server cannot service anything other than WAN-side subscribers?
    IceStorm.TopicManager.Endpoints=default -p 10000
IceStorm.TopicManager.PublishedEndpoints=default -p 10000 -h 5.6.7.8

    Seems like you would need multiple instances of IceStorm, one with a topic manager advertising a LAN-side address (i.e. via PublishedEndpoints) and another advertising a WAN-side address, in order to properly support both WAN and LAN side subscribers.

    Is that right?

    Phil
  • benoit
    benoit Rennes, France
    Hi Philip,

    Yes, if your network is partitioned and IceStorm is listening on both networks, proxies published by IceStorm should contain the endpoints of both networks if clients need to access IceStorm from both networks.

    However, as you discovered, clients will eventually connect to the wrong IP address. To minimize the delays occurred by connecting to the wrong IP address, you could set Ice.Override.ConnectTimeout in your clients. You could also filter the endpoints in your client by examining the endpoints of the proxy (using the ice_getEndpoints() method).

    Another option for IceStorm is to deploy two IceStorm services which are linked together. One instance would listen on the LAN network while the other would listen on the WAN network. See the IceStorm chapter in the Ice manual for more information on linking.

    Cheers,
    Benoit.

Categories