Re: [Resin-interest] Problem with session storage becoming corrupt
On 5/20/14, 12:38 AM, Mathias Lagerwall wrote:
Hi Scott and thanks for the fast answer.0
Is there anything we can do here to help fixing this issue?
You could try disabling JNI, assuming you're not using openssl.
Do you think this will be fixed in 4.0.40 or should I start preparing
for a transition to Linux on all the servers involved?
Well, 4.0.40 just went out, so it would be in 4.0.41. It would certainly
be included in any 4.0.41 fixes. Changing to Linux would also fix the issue.
-- Scott
Best regards
Mathias Lagerwall
---
CTO - Mathias Lagerwall
Netset AB, Adelgatan 9, 211 22 Malmö
Tel +46 (0)40 208800
Mobile +46 (0)733 919103
2014-05-20 0:45 GMT+02:00 Scott Ferguson f...@caucho.com:
On 5/19/14, 6:16 AM, Mathias Lagerwall wrote:
Hi
We are running several clusters with resin-pro and have problems with
the sessions.
We have tried several versions of Resin / Java but the current setup is:
Win Server 2008 R2 SP1
Java 1.7.0_55 from Oracle
Resin-Pro 4.0.39
JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
com.caucho.vfs.JniRandomAccessFile
[2014/05/17 09:33:56.342] {resin-30} Watchdog received warning from
Resin[fi_b,pid=0]:
java.lang.IllegalStateException: block at 0xb1be6000 is invalid for
file /D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db (length
0x8000)
JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
com.caucho.vfs.JniRandomAccessFile
.
The log can become many GB during a day of operation. The sites are
quite busy and a lot of sessions are created. Ferg indicated to me in
an earlier conversation that the length 0x8000 looked strange.
Does this mean that the session storage is too big? Are we somehow
running 32-bit things when we shouldn't?
I have tried to recreate the problem locally on my Linux machine but I
am not able to trigger the error. I am not sure if this has to do with
me running Linux or that my simulated load isn't triggering the error.
It's a windows specific issue, so Linux definitely makes a difference.
Basically, the stat() call on windows returns a 32-bit file length. The
earlier fix calls a separate windows stat call to get the 64-bit file
length. But it looks like there might be another call that wasn't changed.
-- Scott
What can I do to the track this down?
Best regards
Mathias Lagerwall
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Problem with session storage becoming corrupt
Hi Scott and thanks for the fast answer.0
Is there anything we can do here to help fixing this issue?
Do you think this will be fixed in 4.0.40 or should I start preparing
for a transition to Linux on all the servers involved?
Best regards
Mathias Lagerwall
---
CTO - Mathias Lagerwall
Netset AB, Adelgatan 9, 211 22 Malmö
Tel +46 (0)40 208800
Mobile +46 (0)733 919103
2014-05-20 0:45 GMT+02:00 Scott Ferguson f...@caucho.com:
On 5/19/14, 6:16 AM, Mathias Lagerwall wrote:
Hi
We are running several clusters with resin-pro and have problems with
the sessions.
We have tried several versions of Resin / Java but the current setup is:
Win Server 2008 R2 SP1
Java 1.7.0_55 from Oracle
Resin-Pro 4.0.39
JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
com.caucho.vfs.JniRandomAccessFile
[2014/05/17 09:33:56.342] {resin-30} Watchdog received warning from
Resin[fi_b,pid=0]:
java.lang.IllegalStateException: block at 0xb1be6000 is invalid for
file /D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db (length
0x8000)
JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
com.caucho.vfs.JniRandomAccessFile
.
The log can become many GB during a day of operation. The sites are
quite busy and a lot of sessions are created. Ferg indicated to me in
an earlier conversation that the length 0x8000 looked strange.
Does this mean that the session storage is too big? Are we somehow
running 32-bit things when we shouldn't?
I have tried to recreate the problem locally on my Linux machine but I
am not able to trigger the error. I am not sure if this has to do with
me running Linux or that my simulated load isn't triggering the error.
It's a windows specific issue, so Linux definitely makes a difference.
Basically, the stat() call on windows returns a 32-bit file length. The
earlier fix calls a separate windows stat call to get the 64-bit file
length. But it looks like there might be another call that wasn't changed.
-- Scott
What can I do to the track this down?
Best regards
Mathias Lagerwall
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Problem with session storage becoming corrupt
On 5/19/14, 6:16 AM, Mathias Lagerwall wrote:
Hi
We are running several clusters with resin-pro and have problems with
the sessions.
We have tried several versions of Resin / Java but the current setup is:
Win Server 2008 R2 SP1
Java 1.7.0_55 from Oracle
Resin-Pro 4.0.39
JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
com.caucho.vfs.JniRandomAccessFile
[2014/05/17 09:33:56.342] {resin-30} Watchdog received warning from
Resin[fi_b,pid=0]:
java.lang.IllegalStateException: block at 0xb1be6000 is invalid for
file /D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db (length
0x8000)
JniRandomAccessFile[/D:/resin-pro-4.0.39/resin-data/fi_b/distcache/data.db]:class
com.caucho.vfs.JniRandomAccessFile
.
The log can become many GB during a day of operation. The sites are
quite busy and a lot of sessions are created. Ferg indicated to me in
an earlier conversation that the length 0x8000 looked strange.
Does this mean that the session storage is too big? Are we somehow
running 32-bit things when we shouldn't?
I have tried to recreate the problem locally on my Linux machine but I
am not able to trigger the error. I am not sure if this has to do with
me running Linux or that my simulated load isn't triggering the error.
It's a windows specific issue, so Linux definitely makes a difference.
Basically, the stat() call on windows returns a 32-bit file length. The
earlier fix calls a separate windows stat call to get the 64-bit file
length. But it looks like there might be another call that wasn't changed.
-- Scott
What can I do to the track this down?
Best regards
Mathias Lagerwall
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
