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 22:06:43 -0500
- Thread-topic: java.lang.IllegalStateException: Cannot fire array fault with a null handler
I suspect that the underlying issues have been there for awhile. We may have
noticed the errors more because we have been doing a lot of load testing.
Dov
On 12/14/08 9:53 PM, "Lachlan Deck" <email@hidden> wrote:
> One more question : did this start happening after upgrading to WO5.4.3?
>
> On 15/12/2008, at 1:23 PM, Dov Rosenberg wrote:
>
>> According to the docs for EOSharedEditingContext:
>>
>> In multithreaded applications, shared objects can be used safely by
>> many
>> threads at once. Shared editing contexts use NSMultiReaderLocks to
>> maintain
>> thread safety. The methods objectsWithFetchSpecification
>> bindObjectsWithFetchSpecification, faultForGlobalID, and
>> objectForGlobalID
>> are thread safe, but the context must be locked before using any other
>> shared context API.
>>
>> We use EOUtilities.objectWithPrimaryKey() which uses
>> objectsWithFetchSpecification() internally.
>>
>> Dov
>>
>>
>> On 12/14/08 8:42 PM, "Lachlan Deck" <email@hidden> wrote:
>>
>>> Hi Dov,
>>>
>>> On 15/12/2008, at 12:11 PM, Dov Rosenberg wrote:
>>>
>>>> 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.
>>>
>>> ok
>>>
>>>> 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.
>>>
>>> Correct. EOSharedEditingContext does not extend ERXEC. But that's a
>>> different issue.
>>>
>>>> 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.");
>>>> ....
>>>>
>>>> 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
>>>
>>> Yeah - the problem is that for some reason (yet unknown) the array
>>> fault is botched.
>>> I'd suggest pinging Pierre on this one.
>>>
>>> The questions you skipped though could be helpful:
>>> - memory usage?
>>> - anything special about the entities triggering this? (e.g.,
>>> inheritance) Is it marked as shared in the model?
>>>
>>> - are you using locking? Or have you tried using locking? i.e., ERXEC
>>> auto-locking does *not* apply to EOSharedEditingContext.
>>>
>>> EOSharedEditingContext
>>> .defaultSharedEditingContext().lockForReading();
>>> try
>>> {
>>>
>>> }
>>> finally
>>> {
>>>
>>> EOSharedEditingContext
>>> .defaultSharedEditingContext().unlockForReading();
>>> }
>>>
>>>
>>>> On 12/14/08 6:51 PM, "Lachlan Deck" <email@hidden> wrote:
>>>>
>>>>> On 14/12/2008, at 4:10 AM, Dov Rosenberg wrote:
>>>>>
>>>>>> 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
>>>>>
>>>>
>>>
>>> with regards,
>>> --
>>>
>>> Lachlan Deck
>>>
>>>
>>>
>>
>
> 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