Re: Locks within AbstractReadWriteStore
Carsten Ziegeler wrote: Corin Moss wrote: JCS certainly has an implementation of a r/w lock: http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/util s/locking/ ReadWriteLock.html The indexed disk cache certainly uses it, as I suspect does any other cache which needs such a thing. So I guess we should be fine to remove the A-R-W dependency? Yes. It's worth noting that JCS even implements a r/w lock for its JISP implementation, where JISP doesn't do such a thing on its own. :) Does this require a vote? :) No, such changes doesn't require a vote. So you can just go ahead. Done -- Unico
RE: Locks within AbstractReadWriteStore
Corin Moss dijo: > > Hiya, > > JCS certainly has an implementation of a r/w lock: > > http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/utils/locking/ > ReadWriteLock.html While reviewing the code at line 111 is interesting to me why wait full 2 seconds on it. It is a lot of time! Based on my own DB experience, it is better to issue a random wait time ranging from 1 to 1000 ms. It would be faster and avoid threads fighting each other when they entered on the same instant. They will have diferent waiting time. WDYT? Best Regards, Antonio Gallardo
RE: Locks within AbstractReadWriteStore
Corin Moss wrote: > > JCS certainly has an implementation of a r/w lock: > > http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/util > s/locking/ > ReadWriteLock.html > > The indexed disk cache certainly uses it, as I suspect does > any other cache which needs such a thing. So I guess we > should be fine to remove the A-R-W dependency? > Yes. > It's worth noting that JCS even implements a r/w lock for its > JISP implementation, where JISP doesn't do such a thing on its own. :) > > Does this require a vote? :) No, such changes doesn't require a vote. So you can just go ahead. Carsten
RE: Locks within AbstractReadWriteStore
Hiya, JCS certainly has an implementation of a r/w lock: http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/utils/locking/ ReadWriteLock.html The indexed disk cache certainly uses it, as I suspect does any other cache which needs such a thing. So I guess we should be fine to remove the A-R-W dependency? It's worth noting that JCS even implements a r/w lock for its JISP implementation, where JISP doesn't do such a thing on its own. Does this require a vote? :) Corin -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Monday, 8 March 2004 8:40 p.m. To: [EMAIL PROTECTED] Subject: RE: Locks within AbstractReadWriteStore The A-R-W store is just a dump default implementation. The old stores in Cocoon/Avalon weren't synchronized properly, so they sometimes suffered from threading issues. A first easy-to-do solution was the A-R-W store with using the locks. Now, I haven't looked into JCS, but I guess they are doing the synchronization inside JCS (I hope). If this is true, we don't do any syncing/locking in our Store and simply defer the work to JCS. HTH Carsten From: Corin Moss [mailto:[EMAIL PROTECTED] Sent: Sunday, March 07, 2004 11:56 PM To: [EMAIL PROTECTED] Subject: Locks within AbstractReadWriteStore Hi Guys, When I first started looking at the persistent store I mentioned the read/write locks contained within AbstractReadWriteStore as a potential issue. Under load test with the new JCS based store I'm still seeing really high iowait usage after about 10-12 hours (similar to what I noticed with the JISP based store.) I suspect that there may indeed be a problem somewhere within this part of the store. The cache is no longer corrupt after the test (it was with the old JISP store), but it does still take a long time to get anything written to it. What I'll try and do is perform a similar test, outside of the Cocoon environment using the JCS library and see if I can recreate this. I also notice that there's a new release of EDU.oswego.cs.dl.util.concurrent - so I'll have a look at this as well. Carsten - I noticed your tag on the A-R-W store - do you have any more info on this? I realise that it's an Avalon component, but I guess it started its life here with all the other store classes? Let me know if anyone has more experience with this particular class :) Corin Corin Moss Lead Developer TVNZ Interactive +64 9 916 7367 +64 21 403 054 [EMAIL PROTECTED] CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
RE: Locks within AbstractReadWriteStore
The A-R-W store is just a dump default implementation. The old stores in Cocoon/Avalon weren't synchronized properly, so they sometimes suffered from threading issues. A first easy-to-do solution was the A-R-W store with using the locks. Now, I haven't looked into JCS, but I guess they are doing the synchronization inside JCS (I hope). If this is true, we don't do any syncing/locking in our Store and simply defer the work to JCS. HTH Carsten From: Corin Moss [mailto:[EMAIL PROTECTED] Sent: Sunday, March 07, 2004 11:56 PM To: [EMAIL PROTECTED] Subject: Locks within AbstractReadWriteStore Hi Guys, When I first started looking at the persistent store I mentioned the read/write locks contained within AbstractReadWriteStore as a potential issue. Under load test with the new JCS based store I'm still seeing really high iowait usage after about 10-12 hours (similar to what I noticed with the JISP based store.) I suspect that there may indeed be a problem somewhere within this part of the store. The cache is no longer corrupt after the test (it was with the old JISP store), but it does still take a long time to get anything written to it. What I'll try and do is perform a similar test, outside of the Cocoon environment using the JCS library and see if I can recreate this. I also notice that there's a new release of EDU.oswego.cs.dl.util.concurrent - so I'll have a look at this as well. Carsten - I noticed your tag on the A-R-W store - do you have any more info on this? I realise that it's an Avalon component, but I guess it started its life here with all the other store classes? Let me know if anyone has more experience with this particular class :) Corin Corin Moss Lead Developer TVNZ Interactive +64 9 916 7367 +64 21 403 054 [EMAIL PROTECTED] CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz
Re: Locks within AbstractReadWriteStore
Corin Moss dijo: > > Hi Guys, > > When I first started looking at the persistent store I mentioned the > read/write locks contained within AbstractReadWriteStore as a potential > issue. Under load test with the new JCS based store I'm still seeing > really high iowait usage after about 10-12 hours (similar to what I > noticed with the JISP based store.) I suspect that there may indeed be > a problem somewhere within this part of the store. > > The cache is no longer corrupt after the test (it was with the old JISP > store), but it does still take a long time to get anything written to > it. No crash is an enhancement over the older one! Of course we need to see how to reduce the time you suggest. > What I'll try and do is perform a similar test, outside of the > Cocoon environment using the JCS library and see if I can recreate this. Good idea. It will help us to identify where the problem is. > I also notice that there's a new release of > EDU.oswego.cs.dl.util.concurrent - so I'll have a look at this as well. Yep: http://marc.theaimsgroup.com/?t=10779322811&r=1&w=2 I hope the upgrade of the util.concurrent can fix this problem. Best Regards, Antonio Gallardo
