problem with icestorm persisted subscribers?

[skropp]

Hi:

Ice 3.4.1 on Windows Server 2008 R2(x64) C#

I am using 2 topics. Topic "Source" and topic "Target". Source is linked to Target with weight 0. The subscriber is listening on both topics. The publisher is publishing only on topic Source, but the subscriber get messages on both topics.
So this works as expected.
Problem:
When I restart IceStorm, subscriber only receives messages on topic source. I suspect that the freeze fails to store subscribers properly that are connected to a topic that is linked to.
This is what I get the second time in the IceStorm log: Note local address = 0.0.0.0:57450

-- 04/30/11 11:37:34.541 icebox-IceStorm: Network: tcp connection established
local address = 192.168.0.101:57448
remote address = 192.168.0.101:10099
-- 04/30/11 11:37:35.569 icebox-IceStorm: Network: failed to establish tcp connection
local address = 0.0.0.0:57449
remote address = <not connected>
Network.cpp:1387: Ice::ConnectionRefusedException:
connection refused: The remote computer refused the network connection.
-- 04/30/11 11:37:35.600 icebox-IceStorm: Network: trying to establish tcp connection to 192.168.0.101:57369
-- 04/30/11 11:37:36.615 icebox-IceStorm: Network: failed to establish tcp connection
local address = 0.0.0.0:57450
remote address = <not connected>
Network.cpp:1387: Ice::ConnectionRefusedException:
connection refused: The remote computer refused the network connection.
-! 04/30/11 11:37:36.645 icebox-IceStorm: warning: Subscriber:DemoIceStorm/topic.Target1: subscriber offline: Network.cpp:1387: Ice::Connect
ionRefusedException:
connection refused: The remote computer refused the network connection. discarding events: 60s retryCount: -1

I attached the code that replicates this. Config is hard coded.

[bernard]

Hi Sebastian,

I just tried your test-case (Ice 3.4.1 on Windows 7) and was not able to reproduce the problem - everything appears to work as expected. The subscriber gets both source and target messages, event after restarting IceStorm.

This trace:

-- 04/30/11 11:37:35.600 icebox-IceStorm: Network: trying to establish tcp connection to 192.168.0.101:57369

is surprising since your subscriber's object adapter uses port 10099 (btw naming this adapter 'TestPublisher' is a bit confusing).

Make sure you start with a clean IceStorm database when you start your test!

Cheers,
Bernard

[skropp]

Thanks Bernard,
you provided me with the right hint. I did not configure IceStorm's publish endpoints with a port. So my config looked like this:

IceStorm.InstanceName=DemoIceStorm
IceStorm.TopicManager.Endpoints=default -p 10000 -h 192.168.0.101
IceStorm.Publish.Endpoints=default -h 192.168.0.101
IceStorm.Trace.TopicManager=2
IceStorm.Trace.Topic=1
IceStorm.Trace.Subscriber=1
IceStorm.Flush.Timeout=2000
Ice.Trace.Network=2
Freeze.DbEnv.IceStorm.DbHome=Var/IceStorm

As soon as I put:

IceStorm.Publish.Endpoints=default -p 20000 -h 192.168.0.101

everything works as expected.

What I understand is that the port is picked at random if no port is chosen. But why did it only affect subscribers on topic "Target"?
Feels a little strange still.

Thanks, Sebastian

[bernard]

Hi Sebastian,

This makes sense: I was using the configuration for the IceStorm/clock demo, which sets the port for the IceStorm.Publish object adapter:

#
# 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

As documented in the Ice manual (see the bottom of Topic Federation) and in the comment of the sample config file, you must set this port number when using federation ... which is what you're doing here. Usually, the federated topics are in separate IceStorm instances. In your test, they happen to be in the same instance, but IceStorm still behaves the same way, and persists the proxy for your Target1 topic.

Best regards,
Bernard