Re: LockManagerRemoteImpl EOFException on URL

Bruno CROS wrote:
> Thanks.
> 
> I was running servlet under same JVM as the application. So
> LockManagerInMemoryImp couldn't instatiate in servlet configure.
> 
> Once I did 2 servers. I had to upgrade 3 files to get it work :
> 
> - LockManagerRemoteImpl
> - LockManagerServlet (working with Remote)
> - And so LockManagerInMemoryImpl.
> 
> Now it's working. ouf.
>

yeah!

> The question now is : Updates are slower, but how much ? it seems to be x10
> slower.
> 
> I had to measure my batches and the mass load tests but can you tell me if
> there is some setup to get faster? What i'm asking is that : Are 2 servers
> with remote , faster than a big one with InMemory. Depends on
> application...yes. But what do you think about that ?
>

The current distributed lock implementation isn't optimal (servlet based 
on single node). A JavaGroups-based LockManager implementation should be 
much faster (but is missed ;-)).
I would recommend to run OJB on a single server with InMemory locking. 
Alternative you could to try minimize the classes using pessimistic 
locking and use optimistic locking for all uncritical (less concurrent 
modified) classes (this would reduce the pessimistic locking throughput).
The real bottleneck is (normally) the DB-server, so a big DB-server with 
  big cache and a fast network is the most important thing to adjust 
performance.

If you start load tests you could also try to test performance of 
upcoming 1.0.5 (simply check out SVN OJB_1_0_RELEASE branch and call 
'ant jar' to build the OJB jar and 'ant junit' to run OJB test-suite to 
see failures of open issues) and compare the result with 1.0.4.
The fixed issues and improvements for 1.0.5 can be found here:
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/release-notes.txt?view=markup

regards,
Armin

> Best regards.
> 
> Bruno
> 
> 
> 
> On 9/28/06, Bruno CROS <[email protected]> wrote:
>>
>> Hi,
>>
>> I updated from SVN LockManagerFactory and configure is well called now,
>> thanks.
>>
>> the EOFException still remains, it seems there is a problem with
>> serialization of LockInfo and HttpObjectStream.
>>
>> Lot of people seams to have this problem (searching google), but i don't
>> really understand what is it really. I know what serialization is , i 
>> did it
>> (with file), but i can't see where something is wrong in
>> LockManagerRemoteImpl.
>>
>> Thanks for any help.
>>
>> OJB 1.0.4.
>> Sun JVM 1.4
>>
>>
>>
>> On 9/28/06, Bruno CROS <[email protected]> wrote:
>> >
>> >
>> >
>> > Hi,
>> >
>> > Once i'va modified constructor of LockManagerRemoteImpl to initialize
>> > lockserver variable, i started to test LockManagerRemoteImpl and get 
>> into an
>> > EOFException.
>> >
>> >
>> >
>> > URL sun implementation ,  release 1.0.4
>> >
>> > Thanks
>> >
>> >  Caused by: java.io.EOFException
>> >
>> >  at java.io.ObjectInputStream$PeekInputStream.readFully(
>> > ObjectInputStream.java:2165)
>> >
>> >  at java.io.ObjectInputStream$BlockDataInputStream.readShort(
>> > ObjectInputStream.java:2634)
>> >
>> >  at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java
>> > :734)
>> >
>> >  at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)
>> >
>> >  at
>> > 
>> org.apache.ojb.broker.locking.LockManagerRemoteImpl.performRequestObject
>> > (LockManagerRemoteImpl.java:383)
>> >
>> >  at org.apache.ojb.broker.locking.LockManagerRemoteImpl.performRequest(
>> > LockManagerRemoteImpl.java:335)
>> >
>> >  at org.apache.ojb.broker.locking.LockManagerRemoteImpl.releaseLock(
>> > LockManagerRemoteImpl.java:193)
>> >
>> >  ... 41 more
>> >
>>
>>
>