Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
- Subject: Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
- From: Dov Rosenberg <email@hidden>
- Date: Sun, 14 Dec 2008 20:11:11 -0500
- Thread-topic: java.lang.IllegalStateException: Cannot fire array fault with a null handler
Title: Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
We are using WO 5.4.3. We are also use Project Wonder. Not sure how to figure out the Project Wonder version, but it is the latest as of November. I am actually suprised that my stacktrace doesn’t have any Project Wonder classes in it since we are extending ERXEC and such. Perhaps because this editing context is the EOSharedEditing Context. Here are the decompiled lines of WO code that the stack trace is referring to:
com.webobjects.eoaccess.EODatabaseContext.java
public void _fireArrayFault(Object fault)
{
EOAccessArrayFaultHandler handler = (EOAccessArrayFaultHandler)EOFaultHandler.handlerForFault(fault);
if(handler == null)
throw new IllegalStateException("Cannot fire array fault with a null handler.");
....
com.webobjects.eoaccess.EOAccessArrayFaultHandler.java
public void completeInitializationOfObject(Object eo)
{
_EOCheapCopyArray localCopy;
Object localObject;
EOEditingContext ec;
localCopy = _copy;
localObject = eo;
ec = editingContext();
if(ec != null)
_lockResources(ec);
else
_databaseContext.lock();
_databaseContext._fireArrayFault(eo); <--
...
com.webobjects.eocontrol._EOCheapCopyMutableArray.java
public void willRead()
{
if(_faultHandler != null)
{
EOFaultHandler localHandler = _faultHandler;
localHandler.completeInitializationOfObject(this); <--- I assume that since roles in my code was not null that the associated _EOCheapCopyMutableArray would also not be null.
...
MyCode.java
NSArray roles = user.securityRoles();
if (roles != null) {
for (int i = 0; i < roles.count(); ++i) { <--- roles.count() starts the stacktrace. User.securityRoles() returns data under the same user while not under concurrent load. The roles array appears to be valid since it passes the NULL check
On 12/14/08 6:51 PM, "Lachlan Deck" <email@hidden> wrote:
> On 14/12/2008, at 4:10 AM, Dov Rosenberg wrote:
>
>> Our application tends to get this error under load – i.e. Not while
>> a single
>> user is just clicking away. We have been looking into this trying to
>> figure
>> it out but we are somewhat baffled. Here is what we know so far:
>>
>> * When the exception happens we see stack traces that look like the
>> following
>> java.lang.IllegalStateException: Cannot fire array fault with a null
>> handler.
>> at
>> com
>> .webobjects
>> .eoaccess.EODatabaseContext._fireArrayFault(EODatabaseContext.
>> java:4218)
>
> You're using WO5.4 cause that line doesn't match 5.3.3...
> Dig into if there's any reason why EOFaultHandler.handlerForFault
> would return null.
>
>> <...>
>> In both cases we are accessing a relationship in an EO, but the null
>> checks
>> do not prevent the error. It seems like the NSArrays are present but
>> when we
>> try to access a method of the NSArray (count or objectEnumerator)
>> under load
>> it throws the error. It seems that somehow accessing the array is
>> causing
>> EOF to try to resolve the fault before returning it to us and in the
>> process
>> the data is not available.
>
> WO/Wonder version?
>
>> We don’t throw these errors if we try to debug and step thru the
>> code – only
>> under load. These particular EO’s come from the infamous
>> SharedEditingContext. We use the SharedEditingContext because this
>> portion
>> of the app is READONLY and it allows us to share the data between
>> sessions
>> instead of having to refetch is for every session.
>
> Memory usage? Any particular entities that trigger this? (e.g., any
> inheritance).
> How are you faulting the data? Locking?
>
>> Any thoughts would be appreciated
>
> with regards,
> --
>
> Lachlan Deck
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden