Re: [Resin-interest] inode block/fragment mixup???
I have now filed a report here: http://bugs.caucho.com/view.php?id=3025
/Mattias
Mattias Jiderhamn wrote (2008-10-24 20:30):
> Scott Ferguson wrote (2008-10-23 18:39):
>> On Oct 22, 2008, at 12:06 PM, Mattias Jiderhamn wrote:
>>
>>
>>> We have a strange problem with Resin that looks like a bug but might
>>> be
>>> some configuration issue.
>>>
>>> We hit the bug while storing more than the usual amount of data in a
>>> session (during a process that takes quite a lot of time).
>>> If we narrow things down so we store the same kind of data, although
>>> not
>>> as much (and not using so much time), the error does not come about.
>>> The symptoms are that the slow request seems to finish correcly and
>>> the
>>> data is returned to the browser, however on the next request the
>>> session
>>> does no longer exist. Other sessions does not seem to be affected.
>>> There
>>> are errors in the log file which makes me believe the session is lost
>>> during serializing/deserializing.
>>>
>>> With the same input data, the error is always reproducible.
>>>
>>
>> Do you know how large the session is?
> >From what I can see about 7 MB.
>
>> Also, does "finer" show anything interesting?
>>
> See below if there is anything you consider interesting.
>
>> There may be a limit at 64M of session data, but I doubt you're
>> hitting that. It's possible there's an off-by-one issue at one of the
>> boundaries (since the data is split into fragments). Does adding 1 to
>> the session length still produce the same error?
>>
> A quick test with session.setAttribute("foo", "bar") actually seemed
> to do the trick!
> Is there anything specific you would like me to try with regards to this?
>
>
>
> Here is the finer log:
> ...
> [18:00:06.234] Transaction[01:908024ea] committing
> [18:00:06.234] commit-local:
> [EMAIL PROTECTED]
> [18:00:06.328] idle PoolItem[jdbc/exder,7,ManagedConnectionImpl]
> [18:00:07.593] Table[srun_:2] allocating block 270 fragment
> [18:00:07.609] Table[srun_:2] allocating block 271 fragment
> [18:00:07.609] Table[srun_:2] allocating block 272 fragment
> (and so on...)
> [18:00:08.312] Table[srun_:2] allocating block 333 fragment
> [18:00:08.312] Table[srun_:2] allocating block 334 fragment
> [18:00:08.343] java.lang.IllegalStateException: block/fragment mixup
> [18:00:08.343] at
> com.caucho.db.store.Inode.writeBlockAddr(Inode.java:1078)
> [18:00:08.343] at com.caucho.db.store.Inode.appendBlock(Inode.java:492)
> [18:00:08.343] at com.caucho.db.store.Inode.append(Inode.java:388)
> [18:00:08.343] at
> com.caucho.db.store.BlobOutputStream.flushBlock(BlobOutputStream.java:188)
> [18:00:08.343] at
> com.caucho.db.store.BlobOutputStream.write(BlobOutputStream.java:117)
> [18:00:08.343] at
> com.caucho.db.table.BlobColumn.setStream(BlobColumn.java:179)
> [18:00:08.343] at com.caucho.db.table.BlobColumn.set(BlobColumn.java:267)
> [18:00:08.343] at
> com.caucho.db.sql.UpdateQuery.execute(UpdateQuery.java:110)
> [18:00:08.343] at
> com.caucho.db.jdbc.PreparedStatementImpl.execute(PreparedStatementImpl.java:345)
> [18:00:08.343] at
> com.caucho.db.jdbc.PreparedStatementImpl.executeUpdate(PreparedStatementImpl.java:313)
> [18:00:08.343] at
> com.caucho.server.cluster.FileBacking.storeSelfUpdate(FileBacking.java:524)
> [18:00:08.343] at
> com.caucho.server.cluster.FileBacking.storeSelf(FileBacking.java:474)
> [18:00:08.343] at
> com.caucho.server.cluster.FileStore.store(FileStore.java:169)
> [18:00:08.343] at
> com.caucho.server.cluster.ClusterObject.store(ClusterObject.java:414)
> [18:00:08.343] at
> com.caucho.server.session.SessionImpl.save(SessionImpl.java:960)
> [18:00:08.343] at
> com.caucho.server.session.SessionImpl.saveAfterRequest(SessionImpl.java:946)
> [18:00:08.343] at
> com.caucho.server.session.SessionImpl.finish(SessionImpl.java:908)
> [18:00:08.343] at
> com.caucho.server.connection.AbstractHttpRequest.finish(AbstractHttpRequest.java:2506)
> [18:00:08.343] at
> com.caucho.server.http.HttpRequest.finish(HttpRequest.java:1466)
> [18:00:08.343] at
> com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:212)
> [18:00:08.343] at
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266)
> [18:00:08.343] at
> com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:269)
> [18:00:08.343] at
> com.caucho.server.port.TcpConnection.run(TcpConnection.java:603)
> [18:00:08.343] at
> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
> [18:00:08.343] at
> com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
> [18:00:08.343] at java.lang.Thread.run(Thread.java:595)
> [18:00:08.421] Http[15] no-keepalive
> [18:00:08.421] Tcp[,15] closing connection
> TcpConnection[id=http--80-15,socket=JniSocketImpl$15452578[90827352,fd=4488],
> port=Port[null:80]], total=13
> (... six more...)
> [18:01:06.890] Tcp[,6] com.caucho.vfs.ClientDisconnectException:
> client timeout
> [18:01:06.890] Tcp[,6] closin
Re: [Resin-interest] Logs not rotating correctly
Hi Richard, I've filed a bug for this here: http://bugs.caucho.com/view.php?id=3024 If you discover more information, please add it to this bug report. In the meantime, try changing the archive-format to have a filename with a .gz extension to have Resin automatically gzip the rotated logs. This should help with the disk filling up. Take care, Emil On Tue, Oct 21, 2008 at 04:10:12PM +0100, Richard Grantham wrote: > Sorry, you're right. All that is missing. > > I'm running Resin 3.1.7a. My log configuration is as follows: > rollover-period="1D" /> > rollover-period="1D" /> > rollover-period="1D" /> > > > We don't run Resin with Apache as we use a hardware load balancer. > > What I see happening is the log being rotated but a file handle is > maintained on access.log (it's all the logs mentioned above this is > happening with, not just access.log) and not recycled after the log is > rotated. The result is that the log is copied to another file but then > not cleared. It continues to be written to. Hope that makes sense. > > rgds, > > Richard > > > > > Richard Grantham > Development > > --- > [EMAIL PROTECTED] > Limehouse Software Ltd > > DDI: (020) 7566 3336 > Main: (020) 7566 3320 > Fax: (020) 7566 3321 > > Limehouse Software Ltd > Bridewell Gate > 9 Bridewell Place > London > EC4V 6AW > > Manchester Office: > 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR > Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 > > Check out Limehouse Software's innovative solutions > www.limehousesoftware.co.uk - Transforming the way you publish and consult on > information > > The information contained in this e-mail or in any attachments is > confidential and is intended solely for the named addressee only. Access to > this e-mail by anyone else is unauthorised. If you are not the intended > recipient, please notify Limehouse Software Ltd immediately by returning this > e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate > the information. Opinions expressed in this e-mail are those of the sender > and not necessarily the company. Although an active anti-virus policy is > operated, the company accepts no liability for any damage caused by any virus > transmitted by this e-mail, including any attachments.-Original > Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rob Lockstone > Sent: 15 October 2008 15:52 > To: General Discussion for the Resin application server > Subject: Re: [Resin-interest] Logs not rotating correctly > > My first question would be why would you want to maintain (on an ongoing > basis) access logs for what appears to be a pretty busy server? > > An important piece of information that's missing is the version of resin > that you're running. I know from personal experience that older > versions, in the 2.x world, did not properly rotate log files. > > Also, what settings for the logs do you have configured in your resin > configuration? If you're running resin with apache, then (usually) > apache is in control of the access logs, not resin. It's hard to tell > from what you've said how you have resin configured, standalone or with > apache. > > Rob > > On Oct 15, 2008, at 04:33, Richard Grantham wrote: > > > Hi list, > > I've got a major issue with our live servers. The logs don't > appear to > be rotating correctly. This is filling the disk and causing > performance > issues. > > Resin is running as the resin user - therefore will have reduced > permissions but, even so, this shouldn't be happening as that > user is > the owner of the folder that is being written to. > > Any ideas on how to sort this or is it a bug? > > [EMAIL PROTECTED] logs]# ls -l > total 3431672 > -rw-r--r-- 1 resin apache 1073979392 Oct 15 11:30 access.log > -rw-r--r-- 1 resin apache 1073745275 Oct 15 00:50 > access.log.20081015 > -rw-r--r-- 1 resin apache 1073892465 Oct 15 00:52 > access.log.20081015.0052 > -rw-r--r-- 1 resin apache 49848320 Oct 15 00:54 > access.log.20081015.0054 > -rw-r--r-- 1 resin apache 0 Oct 15 00:56 > access.log.20081015.0056 > -rw-r--r-- 1 resin apache 0 Oct 15 00:58 > access.log.20081015.0058 > -rw-r--r-- 1 resin apache 0 Oct 15 01:00 > access.log.20081015.0100 > -rw-r--r-- 1 resin apache 0 Oct 15 01:02 > access.log.20081015.0102 > -rw-r--r-- 1 resin apache 0 Oct 15 01:04 > access.log.20081015.0104 > > > [rest deleted for brevity] > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest Emil Ong Chief Evangelist Caucho Technology, Inc. Tel. (858) 456-0300 mailto:[EMAIL PROTECTE
