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 protected]> 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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
