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