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 21:16:10 -0500
- Thread-topic: java.lang.IllegalStateException: Cannot fire array fault with a null handler
Hadn't really noticed the lockForReading() and unlockForReading() methods.
Perhaps that could stop the objects from mutating while we are trying to
access them under load. Looking thru the code it seems that various methods
like objectsWithFetchSpecification() etc all do a lock() and unlock()
already. If our methods were synchronized that make these calls would that
accomplish the same thing?
The memory usage is pretty good. The app behaves very well under load -
regular garbage collection rhythms.
None of our Entities are marked as shared in the model. We have other
applications that use the same EOModel.
Thanks
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
>
>
>
_______________________________________________
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