Hi,
On Sat, Jan 07, 2006, Stipe Tolj wrote:
> now the X-Mmms-Transaction-Id is of course not transmitted in plain text,
> but as WBXML token. Mbuni decodes the known token. But it's value seems to
> be invalid.
Yes, but I have access to the RFC 2822 message before it was sent to
Mbuni, and there was no X-Mms-Transaction-Id.
I've read thoroughly the code generating Transaction-Id, and hashing,
and discovered a bunch of kannel functions I didn't knew about, but
couldn't find anything wrong.
The only thing I could think of was an OOM error since mbuni had been
running for a while, and woohoo, this is what I found in my kern.log
(I'm ashamed I didn't think of this log during my first round of
investigations):
Jan 6 16:48:17 vm-13 kernel: Out of Memory: Killed process 24624
(mmsrelay).
The good news: mbuni didn't crash but was killed (ie. that explains why
the process disappeared), and it probably didn't handle too well an OOM
error.
The bad news: mbuni probably leaks a bit.
It seems Stipe still found a bug which happened in these conditions (I
doubt it was pure coincidence).
> good point, no idea how this happened "one time". BTW, this was via HTTP
> proxy transported, hence no Kannel WAP GW running in between? Would be
> great if we have the actual byte-content flowing to Mbuni as either
> wapbox.log or ethereal capture to analyze.
This was via a HTTP proxy indeed, and I wasn't running any network
trace at the time it happened. The HTTP proxy logs weren't verbose
enough to get anything useful.
Cheers,
--
Loïc Minier <[EMAIL PROTECTED]>
Current Earth status: NOT DESTROYED
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org
