To provide some closure on this issue, in case anyone looks at this thread in the future:
Turns out Cayenne was totally innocent and this was just a symptom of a simple "Internet double-clicker" issue. A button in my web application invoked a method that deletes an object. If the user double-clicked that button -> the same method was invoked twice -> the later invocation tried to do things with a deleted object -> it's snapshot had been evicted from the cache -> kaboom! But thanks still for the help John! :) Cheers, - hugi > On 7 May 2021, at 20:21, Hugi Thordarson <h...@karlmenn.is> wrote: > > Rethinking this a bit… If it turns out that the snapshot has actually been > evacuated from cache, how should I obtain an instance of the snapshot? And > isn't it a bit odd that a snapshot has been evacuated for an object that's > about to be updated or is that to be expected? > > Cheers, > - hugi > > > >> On 7 May 2021, at 19:55, Hugi Thordarson <h...@karlmenn.is> wrote: >> >>> On 7 May 2021, at 13:34, John Huss <johnth...@gmail.com> wrote: >>> >>> On Fri, May 7, 2021 at 8:18 AM Hugi Thordarson <h...@karlmenn.is> wrote: >>> >>>> Well I'll be… Over two decades of full time Java and I somehow didn't know >>>> about that stack trace omission. Yikes. Thanks! >>> >>> You’ve just never caused an error that bad before right? 😉 >> >> *cough* yes. Of course, that must be it 😁 >> >>>> .... >>>> So it seems either 'snapshot' or 'objAttribute' is null, probably the >>>> snapshot, right? Any ideas why that might be? >>>> >>> >>> Yeah, it would be the snapshot is null. The snapshot cache is limited in >>> size, so it may have purged that entry if you have a busy server. You could >>> try increasing the size of the snapshot cache: >>> >>> org.apache.cayenne.configuration.Constants.SNAPSHOT_CACHE_SIZE_PROPERTY >> >> Good thinking, but I've already got a ginormous snapshot cache (3.000.000) >> for the traffic, so I don't think that's it. >> Going to hammer away on this code path a bit and see if I can replicate the >> error. >> >> >>>> >>>> - hugi >>>> >>>> >>>> >>>>> On 7 May 2021, at 12:53, John Huss <johnth...@gmail.com> wrote: >>>>> >>>>> Or if you have older logs, you can look back farther to find one without >>>>> the cause omitted. >>>>> >>>>> On Fri, May 7, 2021 at 7:52 AM John Huss <johnth...@gmail.com> wrote: >>>>> >>>>>> It will omit the trace if it has happened a very large number of times. >>>> If >>>>>> you restart the server it will start printing it again when it happens. >>>>>> >>>>>> On Fri, May 7, 2021 at 7:26 AM Hugi Thordarson <h...@karlmenn.is> >>>> wrote: >>>>>> >>>>>>> One would think so, but there's just no stack trace printed for the >>>>>>> NullPointerException. >>>>>>> >>>>>>> >>>>>>>> On 7 May 2021, at 12:24, John Huss <johnth...@gmail.com> wrote: >>>>>>>> >>>>>>>> The first line of the stack after the Caused By line would tell you >>>> the >>>>>>>> line with the problem, wouldn't it? What was that line? >>>>>>>> >>>>>>>> On Fri, May 7, 2021 at 7:16 AM Hugi Thordarson <h...@karlmenn.is> >>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> occasionally my users encounter errors when committing changes to the >>>>>>> DB. >>>>>>>>> The relevant part of the stack trace looks like this: >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> org.apache.cayenne.CayenneRuntimeException: [v.4.1 Jul 14 2020 >>>>>>> 10:26:08] >>>>>>>>> Commit Exception >>>>>>>>> at >>>>>>>>> >>>>>>> >>>> org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:774) >>>>>>>>> at >>>>>>>>> >>>>>>> >>>> org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:691) >>>>>>>>> [...removed rest of trace…] >>>>>>>>> Caused by: java.lang.NullPointerException >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> Unfortunately I've been unable to reproduce this error, so before I >>>>>>> dive >>>>>>>>> into it I'm wondering if this looks familiar to anyone, if there are >>>>>>>>> obvious places to look or if there are recommendations for strategies >>>>>>> to >>>>>>>>> debug? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> - hugi >>>>>>> >>>>>>> >>>> >>>> >> >
