[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ZMailer "hangs up" on message queues...

On Wed, Jul 25, 2001 at 02:44:02PM -0700, Michael Loftis wrote:
> We have ferreted out the quirkiness as it were, the filenames do have to
> be numeric, the problem is we don't want to slow down to retrieve the
> inode number for every file we inject into the queue, as this would
> require a (Totally unecessary) stat (or fstat) call.  Complicating
> matters slightly further is the fact we're using Perl as the engine.

  The key thing is:  Decimal encoded unsigned-long value (say: 31 bits)
  (The parsed value is used as a key in several internal databases;
   all over, not only in router's input queue scanner.)

  The key MUST be unique for the lifetime of the message in the spool.
  Easiest method to create such has been the use of i-node number
  of the spool-file, but we could use any magic a'la gettimeofday()
  yields seconds + usecs, add there pid, and use the catenate.

  Because the submission is intended to work even over NFS, some big
  JUJU stuff steps in, and doing fstat() on open file is actually
  your best bet.

  The router uses  'atol()'  function internally..  Which MIGHT
  treat names beginning with 0 as OCTAL...   Oh the joys of UNIX LIBC...

> And actually you have to get the inode number, then convert it to ASCII
> (OK so itoa isn't that expensive, but still...)
> We've found that there is definetly an upper limit as to the length of
> the filename that it will reliably process, if it's over this limit then
> the system chunks out one at a time for a while, vainly trying to search
> for readable messages.  
> Is there any documentation on *Exactly* what all the restrictions and
> such are for the zmailer queuefiles that are dropped in router/ ?


> Thanks,
> Michael

/Matti Aarnio	<mea@nic.funet.fi>
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi