Net::Stomp and the curious timing behaviour

[Raphael Mankin]

On Mon, 2007-01-08 at 14:36 +0000, Dirk Koopman wrote:
> On Mon, 2007-01-08 at 14:03 +0000, Simon Wistow wrote:
> > Java has this messaging API called JMS and one of the implementations is 
> > called ActiveMQ. ActiveMQ uses a binary protocol but can use a simpler 
> > text protocol calle STOMP (Simple Text Orientated Messaging Protocol) 
> > which in most cases is good enough. There are two implementations - one 
> > which sucks and one which was written by our very own Mr Brocard. It 
> > rocks.
> > 
> 
> > However the Perl producer is rock solid at about 100 messages consumed a 
> > second. This seems a little suspicious to me - like something is 
> > wait()ing for 1/100th of a second somewhere deep down in the stack of 
> > IO::Socket::INET but I'm damned if I can find it.
> > 
> 
> Select timeouts and looping probably. Java will, almost certainly, be
> using threads with blocking reads. The default non-zero minimum time you
> can set in the timeval parameter of a select() call (in linux) is 10mS.
> In theory, if a packet comes along in the meantime the select should
> drop before the 10mS is up. Other work (in C not just in perl), is
> starting to make me question whether it actually waits for 10mS
> regardless. 

Once upon a time, hidden in the famous mists of time, there were two
companies (with names that were TLAs) that offered Unix Sys V
implementations. They were slightly different in the way that they
implemented select()/poll(). One of them always waited for the timeout
period, regardless of whether there was data waiting to be read; the
other always waited for data and never timed out.

When I phoned the larger of the two companies to complain about this bug
I was told: "It is not a bug. The manual says 'timeout *or* when data is
ready'. It does not say which will happen". The other company said:
"Yes, it is a bug", but they never fixed it.

> 
> Oh and I would be looking at M. Brocard's stuff for a select statement
> in there first.
> 
> Dirk 
> 
> 
> 
>