Hi,
> Hi Antonio,
>
>> I understood (possibly incorrectly) this meant the second connect would
>> fail. This is not what I'm seeing, I see the second connect succeed
>> silently. Actually, this is nicer for me but I mention it in case it is
>> not what you wanted to happen.
>
> Actually, I would expect it to fail silently.
If it's failing, wouldn't it be better that it was not completely silent
so that the caller knows something is happening? From my python
perspective, I would expect an exception I can catch (obviously not a
complete melt-down, like happened previously). I fail to see when
transparent retries could be advantageous in this case.
>> One more thing, as I said, the second (and subsequent) connect call
>> looks like a no-op for the caller (i.e., any 'send' works the same with
>> one or more previous connects). I was wondering if there is hidden
>> effect like duplicating internal connections (so more resources
>> consumed), or one can assume that it is just the same to call connect
>> once or more times.
>
> What happens underneath is that the second connect fails and tries to
> reconnect to the peer each 0.1 second. Of course, given the other
> connection exists and occupies the identity, it is getting rejected
> over and over again.
I see. Yeah, that doesn't sound very good.
>
> This doesn't look like a good idea. As I've already mentioned, if
> there are cycles in your topology, there's something wrong with your
> design. Try to refactor the design into multiple non-circular topologies.
Yes, I'm trying to do that for my real case. I was just trying to
understand the double-connect issue itself. I think I got it now, feel
free to ignore my opinions from now on :-)
Cheers,
Antonio
>
> Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
