If Activity.log size is different for each server in
server.xml, then second JVM will try to change the size causing this
problem.
Turn trace on with com.ibm.ejs.ras.*=all=enabled specification
and start the server to verify that following trace entries observed.
[4/27/05 6:23:04:824 UTC] 65b75e04 SharedLogWrit > SharedLogWriter -
ctor
[4/27/05 6:23:04:836 UTC] 65b75e04 SharedLogWrit > verifyLogFile
[4/27/05 6:23:04:838 UTC] 65b75e04 SharedLogWrit > processExistingFile
[4/27/05 6:23:04:839 UTC] 65b75e04 SharedLogWrit d processExistingFile -
changing size of log file
[4/27/05 6:23:04:958 UTC] 65b75e04 SharedLogRead e Ctor the free space
size of 2084561 did not match the physical file size 10485760
[4/27/05 6:23:04:958 UTC] 65b75e04 SharedLogRead d fillBuffer - reading
3eb bytes from 52 .... lot more of above
[4/27/05 6:29:41:709 UTC] 65b75e04 SharedLogRead d fillBuffer - firstHalf
reading 28d bytes from location 9ffd73
[4/27/05 6:29:41:709 UTC] 65b75e04 SharedLogRead d fillBuffer - 2nd read
15e bytes from location 52
[4/27/05 6:29:41:709 UTC] 65b75e04 SharedLogRead d checkForMessage
checking location 52
[4/27/05 6:29:41:709 UTC] 65b75e04 SharedLogRead d fillBuffer - reading 4
bytes from 52 [4/27/05 6:29:41:709 UTC] 65b75e04 SharedLogRead >
readBlockSize reading blockSize from location 56
[4/27/05 6:29:41:709 UTC] 65b75e04 SharedLogRead d fillBuffer - reading 4
bytes from 56 [4/27/05 6:29:41:709 UTC] 65b75e04 SharedLogRead <
readBlockSize returning blockSize = 14b
[4/27/05 6:29:41:710 UTC] 65b75e04 SharedLogRead d fillBuffer - reading 4
bytes from 1a5
|