[JDEV] Sparse considerations about server status
temas at box5.net
Thu Aug 9 14:11:49 CDT 2001
Yeah I think sheath is doing stuff with them. The reason I ask about bounces,
is because most of the queues that have set lenght or sizes will bounce back to
sender if they are overflowed (as far as I'm to understand). So although there
isn't guaranteed delivery, there is a response if it can't be. That's why I
say clients shouldn't need ACK's. Although IQ msgs are always discussed.
On Wed, Aug 08, 2001 at 02:51:34PM -0500, Dustin Puryear wrote:
> On 08 Aug 2001 12:16:08 -0500, Thomas Muldowney wrote:
> > Like I posted earlier I need more specifics to investigate this. Having clients
> > build in safeguards is ridiculous! This would be a server bug by far if no
> Well, I spoke with Colin (we are both with Vedalabs) about this and he
> mentioned that Jabber does not guarantee delivery. Is this true? If so
> then any application that requires all messages to be delivered will
> have to include some type of ACK feature.. I would think.
> > bounce is happening and it is actually getting lost somehow. It has high
> > priority in my books, but I need info, debug logs, incoming/outgoing XML for
> > both parties involved, and anything else that will help.
> I can do this. Note however that jabberd has to be under a high load for
> the problem to occur. That means you can expect _a lot_ of debug and log
> data. Perhaps you would like to run the test suite on a personal test
> box? It may be easier for you to see what data you need? Otherwise you
> can expect a 50MB email from me. :)
> Hmm, a while ago a guy from the OSDN asked for developer access to the
> testing tools. It would be nice if he could run it on his test boxes as
> well, but I'm not sure what happened to him.
> Regards, Dustin
> > --temas
> > On Thu, Aug 02, 2001 at 12:04:56PM -0500, Dustin Puryear wrote:
> > > On 29 Jul 2001 23:19:30 +0200, Gian Filippo Pinzari wrote:
> > > > > Notice that at >= 120 user pairs (240 connected users), which equates to
> > > > > 120 msg/sec in this test, my message loss rate varies from 3% to 13%.
> > > > > The average delivery also climbs to .14 seconds, but I don't consider
> > > > > that a problem. (However, the worst case delivery times are bad: > 6
> > > > > seconds for 150 and 160 user pairs.)
> > > > We've just developed a project (client+server) for one of the
> > > > biggest ISP in Italy. We found since the beginning that each
> > > > Jabber server was not able to handle more than a couple hundreds
> > > > client, so we implemented an architecture that load balances the
> > > > traffic among many concurrent servers running on the same or
> > > > different hosts. We also encountered message losses, but we didn't
> > > > care much :-). As Dustin, we thought this was due to client
> > > > problems.
> > >
> > > Well, now that I know someone else has had a similar experience I can
> > > only assume the problem is with jabberd. I had hoped that jabber.org
> > > would confirm this to either be a problem or something they had built
> > > into jabberd, but that information hasn't been very forthcoming.
> > >
> > > In the end I suppose developers using jabberd need to realize that it
> > > only works in low to medium load environments where message delivery is
> > > not a big issue. Unfortunately, I am not sure if the same is true of the
> > > jabber.com server since they didn't present any information on this
> > > topic either.
> > >
> > > Regards, Dustin
> > >
> > > --
> > > Dustin Puryear <dpuryear at usa.net>
> > > http://members.telocity.com/~dpuryear
> > > In the beginning the Universe was created.
> > > This has been widely regarded as a bad move. - Douglas Adams
> > >
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> Dustin Puryear <dpuryear at usa.net>
> In the beginning the Universe was created.
> This has been widely regarded as a bad move. - Douglas Adams
> jdev mailing list
> jdev at jabber.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
More information about the JDev