Fw: [Spread-users] Connection reset using Java API

[Ryan Caudy]

Performance-wise, there's very little difference between using
SELF_DISCARD and simply not joining the group.

However, if you really don't need to receive any of the messages sent
to the group, not joining the group will be slightly more efficient.
All the messages will still be sent to all the Spread daemons, but I
think the implementation is such that Sess_deliver_message will do a
tiny bit less work if Is_self_discard is set to false, regardless of
whether the group has any other members at the daemon.  Additionally,
the groups state exchange algorithm will have one less group member,
resulting in some (insignificant) speedup.

Cheers,
Ryan

On 9/19/07, John Lister <john.lister-spread at kickstone.com> wrote:
> Cheers for the reply. any questions are good as i'm just beginning my
>  experience with spread :)
>
> I have 2 machines on the same subnet, one sends messages and the other
> receives (consumes) them.
> So it looks like you are right, i didn't realise that i had to consume my
> own messages on the same daemon
> while blindly following the examples which join the group.
>
>
> As the sender doesn't need the message am i better not joining the group or
> setting SELF_DISCARD in terms of performance?
>
> Cheers, I would never have thought it was a buffer problem as the number of
> messages seems to be slightly variable, but the time frame between resets is
> almost exact.
>
> JOHN
>
> >> Hi John,
> >>
> >> When you say, "the messages are all being consumed," do you mean that
> >> there is a receiver app that is getting them all?  If your sender app
> >> is joining the destination group(s), then it also needs to receive
> >> those messages to clear the queue at the Spread daemon for its
> >> connection.  If you don't want to have to do that, you can (a) not
> >> have the sender join the destination groups, since Spread supports
> >> open group semantics, or (b) send your messages with the SELF_DISCARD
> >> flag.
> >>
> >> Please ignore this if my assumptions about your sender app aren't
> >> correct.
> >>
> >> Cheers,
> >> Ryan
> >>
> >> On 9/19/07, John Lister <john.lister-spread at kickstone.com> wrote:
> >>>
> >>>
> >>> Hi, i have a simple java app that connects to the spread network sending
> >>> messages using multiple threads. Between them the threads on average
> >>> send
> >>> approx 1 message a second, but occasionally simulate bursting behaviour
> >>> (but
> >>> never more than about 10 messages at a time). However after approx 10300
> >>> messages or almost exactly 3hrs each thread gets a "connection reset"
> >>> error.
> >>> Is there something in spread that limits continuous connections to 3hrs
> >>> and
> >>> if so can i change it, or is something else going on. The messages are
> >>> all
> >>> being consumed so there shouldn't be a buffer full problem.
> >>>
> >>> I can detect the reset and open a new connection, but it seems odd that
> >>> the
> >>> connection is closed especially as it is via the local loop interface.
> >>>
> >>> Any suggestions
> >>>
> >>> Thanks
> >>> --
> >>>
> >>> Got needs? Get Goblin'! - http://www.pricegoblin.co.uk/
> >>>
> >>> _______________________________________________
> >>> Spread-users mailing list
> >>> Spread-users at lists.spread.org
> >>> http://lists.spread.org/mailman/listinfo/spread-users
> >>>
> >>>
> >>
> >
>
>
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users
>