2008-01-02:
[8:04] <zumbrunn> hi MrRio[13:53] <hypersmil> has anybody seen an error like this:[13:53] <hypersmil> [2008/01/02 14:56:55] [ERROR] error storing session data.[13:53] <hypersmil> java.lang.IllegalStateException: XMLList[13:53] <hypersmil> when using persistentSessions[14:12] <zumbrunn> no, haven't come across that[14:12] <zumbrunn> isn't XMLList and e4x object?[14:17] <hypersmil> i'm not doing anything with xml - this happens when i shutdown helma[14:18] <zumbrunn> yes, helma might internally have XMLList objects as well[14:19] <zumbrunn> which are used when serializing[14:19] <zumbrunn> just named the same, but not related to the e4x XMLList[14:19] <zumbrunn> dunno[14:20] <zumbrunn> does this happen every time you shut down?[14:21] * zumbrunn wonders if it depends on the kind of objects/properties that need to be serialized[14:22] <hypersmil> it seems to happen when i don't modify session.data.foobar[14:23] <hypersmil> but i'm not quiet sure[14:30] <hypersmil> ok, i can reporduce the error/exception, it really only happens if you don't modify anything within session.data[14:34] <zumbrunn> can't reproduce it here, though[14:35] <zumbrunn> (current svn version, in my case)[14:35] <zumbrunn> a 1.6.1 ante portas build[14:59] <hypersmil> Starting Helma 1.6.0 (January 2 2008) on Java 1.6.0_01[15:01] <hypersmil> i'm using the following to produce teh error :[15:01] <hypersmil> http://helma.pastebin.com/d14b3e64[15:03] <hypersmil> when you delete the first line and hit the restart link in manage application 2 times it will produce the error[15:29] <zumbrunn> hypersmil, how do you get a Helma 1.6.0 (January 2 2008) build?[15:29] <zumbrunn> Are you checking out from a branch or tag?[15:30] <zumbrunn> or are you on trunk?[15:30] <zumbrunn> cvs or svn?[15:33] <zumbrunn> (because checking out from svn trunk should give you a 1.6.1 version number)[15:34] <hypersmil> http://adele.helma.org/download/helma/nightly/1.6/[15:36] <zumbrunn> ok, I think, currently the nightly builds can not be trusted[15:37] <zumbrunn> they probably are still based on the old cvs repository[15:37] <hypersmil> ;([15:47] <zumbrunn> just tried the code you put in the pastebin...[15:47] <zumbrunn> I still don't get an error[15:47] <hypersmil> i'm currently checking out the svn trunk - i'll try it with that ..[15:48] <hypersmil> do you use helmaswarm?[15:48] <zumbrunn> no, not in my test[15:49] <hypersmil> it's about another issue - i discovered this session thing while investigating a session replication issue in helma swarm, but the buggy result happens in any case (w/wo swarm)[15:52] <hypersmil> i think there is also an issue with swarm / storing hopObjects in session.data / failover in mod_jk - but i haven't been able to reproduce it yet[15:53] <zumbrunn> if you are lucky, it will magically go away with the 1.6.1 build[15:57] <hypersmil> now i got Starting Helma 1.6.1 (January 2 2008) on Java 1.6.0_01[16:00] <hypersmil> same problem[16:02] <zumbrunn> maybe the Java version makes a difference[16:02] <zumbrunn> I can't test with Java 1.6 right now[16:03] <zumbrunn> still on Java 1.5.0_13 on this machine here[16:05] <zumbrunn> (in any case, it's time to file it as a bug, I guess)[16:13] <hypersmil> the results are not clear i think, when trying to reproduce this bug on linux i can't find the exception but my data is also gone[16:15] <zumbrunn> In my case the session data survived as it should[16:55] <hypersmil> i tried it also on debian 4.0 (etch) with java version:[16:56] <hypersmil> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)[16:56] <hypersmil> Java HotSpot(TM) Server VM (build 1.5.0_04-b05, mixed mode)[16:56] <hypersmil> so it seems not to be an java issue - i'm going to file this as a bug - let's see what happens :)[16:57] <zumbrunn> ok, thanks!
In the channel now:
Logs by date: