Mailing List Archive: DBMail: dev

IMAPD "send_data"

Index | Next | Previous | View Threaded

mysql.jorge at decimal

Sep 21, 2009, 2:43 AM

Post #1 of 3 (821 views)
Permalink

IMAPD "send_data"

Howdy,

I do not know the circumstances, imapd show'd me this:

Message from syslogd [at] lir at Mon Sep 21 10:37:23 2009 ...

lira dbmail/imap4d[31518]: [0x8cd7c38] EMERGENCY:[imap] send_data(+80):
[0x8f689058] want [16384] <> got [16382]

1st time I see this since I start using git head on 2/3 month's.

Jorge,

paul at nfg

Sep 21, 2009, 1:49 PM

Post #2 of 3 (742 views)
Permalink

Re: IMAPD "send_data" [In reply to]

Jorge Bastos wrote:
> lira dbmail/imap4d[31518]: [0x8cd7c38] EMERGENCY:[imap] send_data(+80):
> [0x8f689058] want [16384] <> got [16382]

It means dbmail wants to send more data to a client than is available in
the message cache. It's an old and tenacious boundary problem in the
code Jon and I have worked on a lot during the libevent rewrite. This
simply must not happen, hence the EMERG (fatal) tracelevel.

We probably want to lower the tracelevel there for production systems
though, but we also want to fix the problem....

> 1^st time I see this since I start using git head on 2/3 month’s.

That's... not bad. But still one time too many.

--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev [at] dbmail
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev

mysql.jorge at decimal

Sep 21, 2009, 1:57 PM

Post #3 of 3 (740 views)
Permalink

Re: IMAPD "send_data" [In reply to]

I'll try to get you more info about this.
It'll be difficult I believe, since it'll happen when I don't know!

> Jorge Bastos wrote:
> > lira dbmail/imap4d[31518]: [0x8cd7c38] EMERGENCY:[imap]
> send_data(+80):
> > [0x8f689058] want [16384] <> got [16382]
>
> It means dbmail wants to send more data to a client than is available
> in
> the message cache. It's an old and tenacious boundary problem in the
> code Jon and I have worked on a lot during the libevent rewrite. This
> simply must not happen, hence the EMERG (fatal) tracelevel.
>
> We probably want to lower the tracelevel there for production systems
> though, but we also want to fix the problem....
>
> > 1^st time I see this since I start using git head on 2/3 month's.
>
> That's... not bad. But still one time too many.

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev [at] dbmail
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads