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
>>> 0x80000000)
>>>
>>> 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 0x80000000" 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

Reply via email to