the publisher hung when it did the publishment the first time

[gridnt]

Hi All
I am a beginer of ICE and have an issue need to be solved. Anybody can help
me?
When I ran my process, sometime it hung for about 5-6 minutes when it did
the publishment the first time. The process just hung when it did the first
publishment. But if the issue not happend at the first time, it run fluently
and will not hung any more. If the icebox serice and publisher process ran
in the same machine, the probability is very low; otherwise,they run in the
different machine, the probability is about 40%.

The below is my test code, I modified the clock example of Ice-3.4.2-demos
//add 2 lines in the file Publisher.cpp
139 while(true)
140 {
141 cout<<"start"<<endl; // add before send
142 clock->tick(IceUtil::Time::now().toDateTime());
143 cout<<"end"<<endl; // add after send
144 IceUtil::ThreadControl::sleep(IceUtil::Time::secon ds(1));
145 }

Most time, my program can out 'start' and 'end'. When the issue occured,I
just can see the 'start', and the program hung for 5-6 minutes. Anybody has
the same experience,pls teach me to solve it. Thanks a lot of in advance.

gdb stack trace as follow:
#0 0x00000036de60ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000003c6931282a in IceInternal::ConnectRequestHandler::getConnection( bool) () from /usr/lib64/libIce.so.34
#2 0x0000003c693144ba in IceInternal::ConnectRequestHandler::sendRequest(Ic eInternal::Outgoing*) () from /usr/lib64/libIce.so.34
#3 0x0000003c693e390d in IceInternal::Outgoing::invoke() () from /usr/lib64/libIce.so.34
#4 0x00000000004149a5 in IceDelegateM:emo::Clock::tick (this=0x9963fd0, time="10/19/11 16:46:34.523", __context=0x0) at Clock.cpp:147
#5 0x0000000000415144 in IceProxy:emo::Clock::tick (this=0x9963ed0, time="10/19/11 16:46:34.523", __ctx=0x0) at Clock.cpp:71
#6 0x000000000041d6f6 in IceProxy:emo::Clock::tick (this=0x9963ed0, time="10/19/11 16:46:34.523") at ./Clock.h:111
#7 0x000000000041c25d in Publisher::run (this=0x7fffa294e640, argc=1, argv=0x7fffa294e748) at Publisher.cpp:142
#8 0x0000003c692f89d8 in Ice::Application::doMain(int, char**, Ice::InitializationData const&) () from /usr/lib64/libIce.so.34
#9 0x0000003c692f9825 in Ice::Application::main(int, char**, Ice::InitializationData const&) () from /usr/lib64/libIce.so.34
#10 0x0000003c692fa38d in Ice::Application::main(int, char**, char const*) () from /usr/lib64/libIce.so.34
#11 0x000000000041c456 in main (argc=2, argv=0x7fffa294e748) at Publisher.cpp:30

My test bed:
OS：CentOS 5 64bits
ICE：3.4.2

The config files:
config.pub:
#
# This property is used by the clients to connect to IceStorm.
#
TopicManager.Proxy=DemoIceStorm/TopicManager:tcp -h 192.168.3.94 -p 10000

#
# Network Tracing
#
# 0 = no network tracing
# 1 = trace connection establishment and closure
# 2 = like 1, but more detailed
# 3 = like 2, but also trace data transfer
#
#Ice.Trace.Network=1

config.icebox:
#
# The IceStorm service instance name.
#
IceStorm.InstanceName=DemoIceStorm
Ice.MessageSizeMax=51200
#
# This property defines the endpoints on which the IceStorm
# TopicManager listens.
#
IceStorm.TopicManager.Endpoints=default -p 10000

#
# This property defines the endpoints on which the topic
# publisher objects listen. If you want to federate
# IceStorm instances this must run on a fixed port (or use
# IceGrid).
#
IceStorm.Publish.Endpoints=tcp -p 10001:udp -p 10001

#
# TopicManager Tracing
#
# 0 = no tracing
# 1 = trace topic creation, subscription, unsubscription
# 2 = like 1, but with more detailed subscription information
#
IceStorm.Trace.TopicManager=2

#
# Topic Tracing
#
# 0 = no tracing
# 1 = trace unsubscription diagnostics
#
IceStorm.Trace.Topic=1

#
# Subscriber Tracing
#
# 0 = no tracing
# 1 = subscriber diagnostics (subscription, unsubscription, event
# propagation failures)
#
IceStorm.Trace.Subscriber=1

#
# Amount of time in milliseconds between flushes for batch mode
# transfer. The minimum allowable value is 100ms.
#
IceStorm.Flush.Timeout=2000

#
# Network Tracing
#
# 0 = no network tracing
# 1 = trace connection establishment and closure
# 2 = like 1, but more detailed
# 3 = like 2, but also trace data transfer
#
#Ice.Trace.Network=1

#
# This property defines the home directory of the Freeze
# database environment for the IceStorm service.
#
Freeze.DbEnv.IceStorm.DbHome=db

[bernard]

Hello,

Welcome to our forums!

I suspect this hang is caused by the following:

- the computer where your IceStorm server is running has multiple network interfaces, and only one of them is reachable by your client/publisher.

- you configured IceStorm to listen on all these interfaces, and to include ("publish") all these interfaces in the proxies it creates (no -h is equivalent to -h *):

#
# This property defines the endpoints on which the IceStorm
# TopicManager listens.
#
IceStorm.TopicManager.Endpoints=default -p 10000

#
# This property defines the endpoints on which the topic
# publisher objects listen. If you want to federate
# IceStorm instances this must run on a fixed port (or use
# IceGrid).
#
IceStorm.Publish.Endpoints=tcp -p 10001:udp -p 10001

- your publisher/client gets a proxy with all these interfaces (endpoints), attempts to connect to an unreachable endpoint, and this connection attempt takes several minutes to fail

- Ice then tries the next endpoint, the connection establishment succeeds, and the next requests reuse this established connection.

The solution is to specify the interfaces to listen on and publish in your object adapter Endpoints configuration, i.e.:

IceStorm.TopicManager.Endpoints=tcp -h 192.168.3.94 -p 10000
IceStorm.Publish.Endpoints=tcp -h 192.168.3.94 -p 10001:udp -h 192.168.3.94 -p 10001

This way, the first connection attempt will use the desired endpoint and succeed.

See Object Adapter Endpoints - Ice 3.4 - ZeroC for more details on this topic.

Best regards,
Bernard

[gridnt]

I have no problem with the test yesterday.Thank you very much.