Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java

[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/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java

[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