You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by un...@apache.org on 2004/02/27 18:27:04 UTC
cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
unico 2004/02/27 09:27:04
Modified: src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java
DefaultEventRegistryImpl.java
Log:
fix NPE on first use
Revision Changes Path
1.4 +2 -1 cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/StoreEventRegistryImpl.java
Index: StoreEventRegistryImpl.java
===================================================================
RCS file: /home/cvs/cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/StoreEventRegistryImpl.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StoreEventRegistryImpl.java 7 Feb 2004 15:20:09 -0000 1.3
+++ StoreEventRegistryImpl.java 27 Feb 2004 17:27:04 -0000 1.4
@@ -113,6 +113,7 @@
return true;
} else {
getLogger().warn("Unable to recover Event Registry.");
+ super.createBlankCache();
return false;
}
}
1.10 +5 -3 cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/DefaultEventRegistryImpl.java
Index: DefaultEventRegistryImpl.java
===================================================================
RCS file: /home/cvs/cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/DefaultEventRegistryImpl.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- DefaultEventRegistryImpl.java 10 Dec 2003 05:31:01 -0000 1.9
+++ DefaultEventRegistryImpl.java 27 Feb 2004 17:27:04 -0000 1.10
@@ -190,7 +190,9 @@
ctx.getRealPath("/WEB-INF"),
DefaultEventRegistryImpl.PERSISTENT_FILE);
if (m_persistentFile == null) {
- throw new ContextException("Could not obtain persistent file. " + "The cache event registry cannot be " + "used inside an unexpanded WAR file.");
+ throw new ContextException("Could not obtain persistent file. " +
+ "The cache event registry cannot be " +
+ "used inside an unexpanded WAR file.");
}
}
@@ -305,7 +307,7 @@
}
// TODO: don't hardcode initial size
- private void createBlankCache() {
+ protected final void createBlankCache() {
this.m_eventMMap = new MultiHashMap(100);
this.m_keyMMap = new MultiHashMap(100);
}
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Unico Hommes <un...@hippo.nl>.
Joerg Heinicke wrote:
> Unico Hommes <unico <at> hippo.nl> writes:
>
>
>>Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
>>keeps saying:
>>
>>ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
>>(Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
>>Exception
>>java.io.IOException: Bad file descriptor
>> at java.io.RandomAccessFile.length(Native Method)
>
>
> <snip/>
>
>>Not having closely followed the Jisp bug thread. Is this the known issue?
>
>
> Charles Yates has added a bug
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26932) with the same
> stacktrace and he wrote as summary 'DefaultPersistentStore disposed before
> DefaultStore on shutdown'. If that's the reason it shall be easy to fix, shall
> it not? Though it's a really strange error message for an access to an already
> disposed object. Had anybody a look on it? Maybe it would be interesting where
> he get his impression from? Maybe he is listening ... ?
>
It's very well possible that that is the reason though. I recently
noticed that this was happening also.
The problem I encountered was that some components (such as DefaultStore
I presume - and StoreEventCacheRegistry in the case I was looking at)
use the persistent store upon disposal. Now if the
DefaultPersistentStore is already disposed this could cause problems.
Unfortunately I don't see an easy solution ATM since AFAIK ECM doesn't
provide control over shutdown order (Fortress does BTW).
Anyone any ideas?
--
Unico
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Joerg Heinicke <jo...@gmx.de>.
Unico Hommes <unico <at> hippo.nl> writes:
> Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
> keeps saying:
>
> ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
> (Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
> Exception
> java.io.IOException: Bad file descriptor
> at java.io.RandomAccessFile.length(Native Method)
<snip/>
> Not having closely followed the Jisp bug thread. Is this the known issue?
Charles Yates has added a bug
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26932) with the same
stacktrace and he wrote as summary 'DefaultPersistentStore disposed before
DefaultStore on shutdown'. If that's the reason it shall be easy to fix, shall
it not? Though it's a really strange error message for an access to an already
disposed object. Had anybody a look on it? Maybe it would be interesting where
he get his impression from? Maybe he is listening ... ?
Joerg
Re: cvs commit:
cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/implSt
oreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Antonio Gallardo <ag...@agssa.net>.
Unico Hommes dijo:
>
>
> Unico Hommes wrote:
>
>>
>>
>> Antonio Gallardo wrote:
>>
>>> Unico Hommes dijo:
>>>
>>>> Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
>>>> keeps saying:
>>>>
>>>> ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
>>>> (Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
>>>> Exception
>>>> java.io.IOException: Bad file descriptor
>>>> at java.io.RandomAccessFile.length(Native Method)
>>>
>>>
>>>
>>> I think we can update to jisp 2.5.6 (the lastest version with a
>>> compatible
>>> license). Currently in Cocoon is version 2.5.1
>>>
>
> Could you give me a pointer to the download though, I can't seem to find
> it :-/ . http://www.coyotegulch.com/jisp/ seem to only have the 3.0.0
> version.
I tried to find it, but later discovered this is not a 2.5.6 version. It
is a 2.6 version. I googled and yahooed looking for the 2.6 and don't
found it.
Best Regards,
Antonio Gallardo
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/implSt
oreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Unico Hommes <un...@hippo.nl>.
Unico Hommes wrote:
>
>
> Antonio Gallardo wrote:
>
>> Unico Hommes dijo:
>>
>>> Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
>>> keeps saying:
>>>
>>> ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
>>> (Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
>>> Exception
>>> java.io.IOException: Bad file descriptor
>>> at java.io.RandomAccessFile.length(Native Method)
>>
>>
>>
>> I think we can update to jisp 2.5.6 (the lastest version with a
>> compatible
>> license). Currently in Cocoon is version 2.5.1
>>
Could you give me a pointer to the download though, I can't seem to find
it :-/ . http://www.coyotegulch.com/jisp/ seem to only have the 3.0.0
version.
Unico
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/implSt
oreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Unico Hommes <un...@hippo.nl>.
Antonio Gallardo wrote:
> Unico Hommes dijo:
>
>>Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
>>keeps saying:
>>
>>ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
>>(Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
>>Exception
>>java.io.IOException: Bad file descriptor
>> at java.io.RandomAccessFile.length(Native Method)
>
>
> I think we can update to jisp 2.5.6 (the lastest version with a compatible
> license). Currently in Cocoon is version 2.5.1
>
I will check it, see if it solves the problem.
Unico
Re: cvs commit:
cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/implSt
oreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Antonio Gallardo <ag...@agssa.net>.
Unico Hommes dijo:
> Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
> keeps saying:
>
> ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
> (Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
> Exception
> java.io.IOException: Bad file descriptor
> at java.io.RandomAccessFile.length(Native Method)
I think we can update to jisp 2.5.6 (the lastest version with a compatible
license). Currently in Cocoon is version 2.5.1
WDYT?
Best Regards,
Antonio Gallardo.
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Unico Hommes <un...@hippo.nl>.
Unico Hommes wrote:
>
>
<snip/>
>>
>> Ok, I committed my changes - you may want to check it out. I don't
>> think this one introduced any new functionality. However, one thing
>> came to light (again). With (at least) the jetty setup used in
>> cocoon.sh servlet the persistent cache does not persist between
>> startups. The cache dir seems to be the same, but cached items aren't
>> found. I haven't worked out if its a Store bug, or the old Jetty
>> non-reuse of work directory issue.
>>
>
> Should be the latter. This is a matter of tweeking the settings in
> cocoon.xconf and web.xml.
>
> It may be worth changing the default settings so that caching will work
> out-of-the-box with Jetty. Uncomment the 'cache-directory' parameter in
> web.xml?
>
Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
keeps saying:
ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
(Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
Exception
java.io.IOException: Bad file descriptor
at java.io.RandomAccessFile.length(Native Method)
at
com.coyotegulch.jisp.ObjectDatabaseFile.writeObject(ObjectDatabaseFile.java:227)
at
com.coyotegulch.jisp.IndexedObjectDatabase.write(IndexedObjectDatabase.java:199)
at
org.apache.excalibur.store.impl.AbstractJispFilesystemStore.doStore(AbstractJispFilesystemStore.java:148)
at
org.apache.excalibur.store.impl.AbstractReadWriteStore.store(AbstractReadWriteStore.java:110)
at
org.apache.cocoon.caching.impl.StoreEventRegistryImpl.persist(StoreEventRegistryImpl.java:73)
And not only when used by the event registry because these are in my
logs as well:
ERROR (2004-02-29) 14:23.34:274 [core.store.persistent]
(Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
Exception
java.io.IOException: Bad file descriptor
at java.io.RandomAccessFile.length(Native Method)
at
com.coyotegulch.jisp.ObjectDatabaseFile.writeObject(ObjectDatabaseFile.java:227)
at
com.coyotegulch.jisp.IndexedObjectDatabase.write(IndexedObjectDatabase.java:199)
at
org.apache.excalibur.store.impl.AbstractJispFilesystemStore.doStore(AbstractJispFilesystemStore.java:148)
at
org.apache.excalibur.store.impl.AbstractReadWriteStore.store(AbstractReadWriteStore.java:110)
at
org.apache.excalibur.store.impl.MRUMemoryStore.dispose(MRUMemoryStore.java:164)
Not having closely followed the Jisp bug thread. Is this the known issue?
Unico
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Unico Hommes <un...@hippo.nl>.
Geoff Howard wrote:
> Vadim Gritsenko wrote:
>
>> Unico Hommes wrote:
>>
>>> Geoff Howard wrote:
>>>
>>>> unico@apache.org wrote:
>>>>
>>>>> unico 2004/02/27 09:27:04
>>>>>
>>>>> Modified:
>>>>> src/blocks/eventcache/java/org/apache/cocoon/caching/impl
>>>>> StoreEventRegistryImpl.java
>>>>> DefaultEventRegistryImpl.java
>>>>> Log:
>>>>> fix NPE on first use
>>>>
>>>>
>>>>
>>>> FYI I recently re-started making the StoreEventReg default, renaming
>>>> DefaultEventReg, refactoring inheritance a little (pulled out an
>>>> AbstractEventRegistry which both inherit from) etc. It's quite
>>>> unfinished and I have close to no time right now for "play" but just
>>>> wanted to give you a heads up that I have some refactor work going
>>>> on. Next chance I get, I'll try to get it in a working state and
>>>> either commit it or pass it on as a patch for someone else to pick
>>>> up. I'd like to close the open bug about the serialized data
>>>> location not being configurable but couldn't stand to hack in
>>>> configuration when we've already agreed that some refactoring was
>>>> needed.
>>>
>>>
>>>
>>> Great, the bugzilla entry was also in the back of my mind. I've been
>>> using the current default registry in production sites until now but
>>> still had on my todo list to use the persistent store delegating one.
>>
>>
>
> Ok, I committed my changes - you may want to check it out. I don't
> think this one introduced any new functionality. However, one thing
> came to light (again). With (at least) the jetty setup used in
> cocoon.sh servlet the persistent cache does not persist between
> startups. The cache dir seems to be the same, but cached items aren't
> found. I haven't worked out if its a Store bug, or the old Jetty
> non-reuse of work directory issue.
>
Should be the latter. This is a matter of tweeking the settings in
cocoon.xconf and web.xml.
It may be worth changing the default settings so that caching will work
out-of-the-box with Jetty. Uncomment the 'cache-directory' parameter in
web.xml?
Unico
>> Can one of you guys kill tabs in those files while you are at it?
>
>
>
> Tabs and line endings should be fixed now. Eclipse M7 still doesn't
> seem to have a global preference for line endings (and I can't tell if
> its cvs client can be configured to auto-translate), and zapping already
> existing tabs is tough. Oh well, I like everything else but I thought
> I'd give Vadim "fuel for the fire". :)
>
> Geoff
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Geoff Howard <co...@leverageweb.com>.
Vadim Gritsenko wrote:
> Unico Hommes wrote:
>
>> Geoff Howard wrote:
>>
>>> unico@apache.org wrote:
>>>
>>>> unico 2004/02/27 09:27:04
>>>>
>>>> Modified:
>>>> src/blocks/eventcache/java/org/apache/cocoon/caching/impl
>>>> StoreEventRegistryImpl.java
>>>> DefaultEventRegistryImpl.java
>>>> Log:
>>>> fix NPE on first use
>>>
>>>
>>> FYI I recently re-started making the StoreEventReg default, renaming
>>> DefaultEventReg, refactoring inheritance a little (pulled out an
>>> AbstractEventRegistry which both inherit from) etc. It's quite
>>> unfinished and I have close to no time right now for "play" but just
>>> wanted to give you a heads up that I have some refactor work going
>>> on. Next chance I get, I'll try to get it in a working state and
>>> either commit it or pass it on as a patch for someone else to pick
>>> up. I'd like to close the open bug about the serialized data
>>> location not being configurable but couldn't stand to hack in
>>> configuration when we've already agreed that some refactoring was
>>> needed.
>>
>>
>> Great, the bugzilla entry was also in the back of my mind. I've been
>> using the current default registry in production sites until now but
>> still had on my todo list to use the persistent store delegating one.
>
Ok, I committed my changes - you may want to check it out. I don't
think this one introduced any new functionality. However, one thing
came to light (again). With (at least) the jetty setup used in
cocoon.sh servlet the persistent cache does not persist between
startups. The cache dir seems to be the same, but cached items aren't
found. I haven't worked out if its a Store bug, or the old Jetty
non-reuse of work directory issue.
> Can one of you guys kill tabs in those files while you are at it?
Tabs and line endings should be fixed now. Eclipse M7 still doesn't
seem to have a global preference for line endings (and I can't tell if
its cvs client can be configured to auto-translate), and zapping already
existing tabs is tough. Oh well, I like everything else but I thought
I'd give Vadim "fuel for the fire". :)
Geoff
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Unico Hommes wrote:
> Geoff Howard wrote:
>
>> unico@apache.org wrote:
>>
>>> unico 2004/02/27 09:27:04
>>>
>>> Modified: src/blocks/eventcache/java/org/apache/cocoon/caching/impl
>>> StoreEventRegistryImpl.java
>>> DefaultEventRegistryImpl.java
>>> Log:
>>> fix NPE on first use
>>
>>
>> FYI I recently re-started making the StoreEventReg default, renaming
>> DefaultEventReg, refactoring inheritance a little (pulled out an
>> AbstractEventRegistry which both inherit from) etc. It's quite
>> unfinished and I have close to no time right now for "play" but just
>> wanted to give you a heads up that I have some refactor work going
>> on. Next chance I get, I'll try to get it in a working state and
>> either commit it or pass it on as a patch for someone else to pick
>> up. I'd like to close the open bug about the serialized data
>> location not being configurable but couldn't stand to hack in
>> configuration when we've already agreed that some refactoring was
>> needed.
>
>
> Great, the bugzilla entry was also in the back of my mind. I've been
> using the current default registry in production sites until now but
> still had on my todo list to use the persistent store delegating one.
>
Can one of you guys kill tabs in those files while you are at it?
Vadim
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Unico Hommes <un...@hippo.nl>.
Geoff Howard wrote:
> unico@apache.org wrote:
>
>> unico 2004/02/27 09:27:04
>>
>> Modified: src/blocks/eventcache/java/org/apache/cocoon/caching/impl
>> StoreEventRegistryImpl.java
>> DefaultEventRegistryImpl.java
>> Log:
>> fix NPE on first use
>>
>
> FYI I recently re-started making the StoreEventReg default, renaming
> DefaultEventReg, refactoring inheritance a little (pulled out an
> AbstractEventRegistry which both inherit from) etc. It's quite
> unfinished and I have close to no time right now for "play" but just
> wanted to give you a heads up that I have some refactor work going
> on. Next chance I get, I'll try to get it in a working state and
> either commit it or pass it on as a patch for someone else to pick
> up. I'd like to close the open bug about the serialized data location
> not being configurable but couldn't stand to hack in configuration
> when we've already agreed that some refactoring was needed.
Great, the bugzilla entry was also in the back of my mind. I've been
using the current default registry in production sites until now but
still had on my todo list to use the persistent store delegating one.
>
> Don't quite get what was wrong before this commit by the way. Was
> this throwing an NPE all this time? (don't think so...)
>
Yes, the key map never got initialized.
Unico
Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl
StoreEventRegistryImpl.java DefaultEventRegistryImpl.java
Posted by Geoff Howard <co...@leverageweb.com>.
unico@apache.org wrote:
>unico 2004/02/27 09:27:04
>
> Modified: src/blocks/eventcache/java/org/apache/cocoon/caching/impl
> StoreEventRegistryImpl.java
> DefaultEventRegistryImpl.java
> Log:
> fix NPE on first use
>
>
FYI I recently re-started making the StoreEventReg default, renaming
DefaultEventReg, refactoring inheritance a little (pulled out an
AbstractEventRegistry which both inherit from) etc. It's quite
unfinished and I have close to no time right now for "play" but just
wanted to give you a heads up that I have some refactor work going on.
Next chance I get, I'll try to get it in a working state and either
commit it or pass it on as a patch for someone else to pick up. I'd
like to close the open bug about the serialized data location not being
configurable but couldn't stand to hack in configuration when we've
already agreed that some refactoring was needed.
Don't quite get what was wrong before this commit by the way. Was this
throwing an NPE all this time? (don't think so...)
Geoff