« Return to Thread: ConcurrentModificationException, Cannot begin a new event ... - reproducible
Re: ConcurrentModificationExceptio
by Endre Stølsvik-8
::
Rate this Message:
Well, okay - but I guess in the example Holger pastes, the exception
originates at the point of changing the data - not in the event
processing pipeline. Thus, by always committing (or maybe not start
the transaction until the data is changed - what would be the actual
difference in this case? Locking is done outside..), the error would
be contained fully. I get this hunch that this would more often be the
case than the error cropping up in the pipeline. This because the
pipeline-initiated changes often are more of a
"automatic"/"procedural" nature executed by library code, while the
direct list manipulations aren't.
Also, I don't quite see the argument _against trying_ to contain the
exception. The exception would still be raised (fast fail, of course),
the question here is how contained the error would be. Again, in
Holger's example code, if the user actually invoked set(...) there,
the error would have been fully contained - but the method would
obviously have thrown. If the error instead came from commit() (thus
came from the pipeline updates), no guarantees regarding the pipeline
states could be made at all - but it would in any case not be
_completely_ trashed in the way that the state of the transaction
wasn't finished - and the method would obviously still have thrown.
Thus, in both cases, the user would have been directly notified about
the error - but one would on the other side not have a GUARANTEE that
the application state was completely fucked over, as one now have.
Endre.
On Sun, Apr 26, 2009 at 14:30, James Lemieux <jplemieux@...> wrote:
> It's highly unlikely that a pipeline, or any related listeners will be
> consistent if a RuntimeException occurs while delivering a ListEvent. I
> think failing hard and failing often is the optimal approach in this case,
> and if I were to improve the current behaviour, I'd simply make it throw a
> more appropriate type of Exception with a descriptive message.
>
> The "big reason a commit cannot finish despite the error" is because an
> EventList in the pipeline failed to build and deliver a proper ListEvent
> downstream. In fact, it may have only finished reacting to a portion of the
> ListEvent it was delivered at the time it throw its RuntimeException. This
> type of inconsistency cannot be tolerated, and it could lead to red-herring
> types of error reports where subsequent strange behaviour is reported as the
> bug rather than the root cause: a RuntimeException during the delivery of a
> *prior* ListEvent.
>
> James
>
> On Sun, Apr 26, 2009 at 4:52 AM, Emil Crumhorn <emil.crumhorn@...>
> wrote:
>>
>> I completely agree. It seems to me it should be possible to make a
>> "mistake"
>> without getting the entire list system out of order. Normal java lists
>> just
>> continue to work even if you mess up the index (after throwing an
>> exception
>> of course).
>>
>> Unless there's a big reason why the commit can't finish despite the error,
>> it seems to me this would be an easy fix and at least you'd get the lists
>> back on track. Now I have to explicitly check indexes before a set just so
>> that I never get an IndexOutOfBounds exception, as if I get one, then I
>> can't use the lists anymore.
>>
>> Emil
>>
>>
>> Endre Stølsvik-8 wrote:
>> >
>> > I've been wondering about this: shouldn't the beginEvent-commitEvent
>> > always be in a try-finally block? This to contain any errors as best
>> > one can? It seems to me like any error anywhere in the pipeline now
>> > will lead to an irreparably inconsistent state, while if one had
>> > try-finally, with the updates.["change"] always after the actual data
>> > change invocation method, one would get something that at least in
>> > several situations resembles a transaction with both commit and
>> > rollback semantics.
>> >
>> > This would be so that even though there are some logic errors to could
>> > come up in certain situations, the application using GL would still
>> > have a chance of being consistent after an error - of being able to
>> > recover out of errors.
>> >
>> > Endre.
>> >
>> > On Sun, Apr 26, 2009 at 11:06, Holger Brands <hbrands@...> wrote:
>> >> > Is this the expected behavior?
>> >>
>> >> Yes, with the current implementation, that's expected.
>> >> If you dive into the implementation you'll see this:
>> >>
>> >> public E set(int index, E element) {
>> >> // create the change event
>> >> updates.beginEvent();
>> >> // do the actual set
>> >> E previous = data.set(index, element);
>> >> // fire the event
>> >> updates.elementUpdated(index, previous);
>> >> updates.commitEvent();
>> >> return previous;
>> >> }
>> >>
>> >> Event delivery is guarded by calls to
>> >> ListEventAssembler.beginEvent() - start recording changes
>> >> and
>> >> ListEventAssembler.commitEvent() - propagate recorded changes
>> >>
>> >> When an uncaught exception is thrown inbetween, commitEvent()
>> >> is never called and no change events are fired.
>> >> With the next call to beginEvent() the ListEventAssembler detects,
>> >> that an event delivery is in progress leading to the
>> >> ConcurrentModificationExceptions
>> >> you observed.
>> >>
>> >> Holger
>> >>
>> >> __________________________________________________________________________
>> >> Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und
>> >> viele
>> >> ausländische Netze zum gleichen Preis!
>> >> https://produkte.web.de/webde_sms/sms
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/ConcurrentModificationException%2C-Cannot-begin-a-new-event-...---reproducible-tp23172207p23241485.html
>> Sent from the GlazedLists - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
originates at the point of changing the data - not in the event
processing pipeline. Thus, by always committing (or maybe not start
the transaction until the data is changed - what would be the actual
difference in this case? Locking is done outside..), the error would
be contained fully. I get this hunch that this would more often be the
case than the error cropping up in the pipeline. This because the
pipeline-initiated changes often are more of a
"automatic"/"procedural" nature executed by library code, while the
direct list manipulations aren't.
Also, I don't quite see the argument _against trying_ to contain the
exception. The exception would still be raised (fast fail, of course),
the question here is how contained the error would be. Again, in
Holger's example code, if the user actually invoked set(...) there,
the error would have been fully contained - but the method would
obviously have thrown. If the error instead came from commit() (thus
came from the pipeline updates), no guarantees regarding the pipeline
states could be made at all - but it would in any case not be
_completely_ trashed in the way that the state of the transaction
wasn't finished - and the method would obviously still have thrown.
Thus, in both cases, the user would have been directly notified about
the error - but one would on the other side not have a GUARANTEE that
the application state was completely fucked over, as one now have.
Endre.
On Sun, Apr 26, 2009 at 14:30, James Lemieux <jplemieux@...> wrote:
> It's highly unlikely that a pipeline, or any related listeners will be
> consistent if a RuntimeException occurs while delivering a ListEvent. I
> think failing hard and failing often is the optimal approach in this case,
> and if I were to improve the current behaviour, I'd simply make it throw a
> more appropriate type of Exception with a descriptive message.
>
> The "big reason a commit cannot finish despite the error" is because an
> EventList in the pipeline failed to build and deliver a proper ListEvent
> downstream. In fact, it may have only finished reacting to a portion of the
> ListEvent it was delivered at the time it throw its RuntimeException. This
> type of inconsistency cannot be tolerated, and it could lead to red-herring
> types of error reports where subsequent strange behaviour is reported as the
> bug rather than the root cause: a RuntimeException during the delivery of a
> *prior* ListEvent.
>
> James
>
> On Sun, Apr 26, 2009 at 4:52 AM, Emil Crumhorn <emil.crumhorn@...>
> wrote:
>>
>> I completely agree. It seems to me it should be possible to make a
>> "mistake"
>> without getting the entire list system out of order. Normal java lists
>> just
>> continue to work even if you mess up the index (after throwing an
>> exception
>> of course).
>>
>> Unless there's a big reason why the commit can't finish despite the error,
>> it seems to me this would be an easy fix and at least you'd get the lists
>> back on track. Now I have to explicitly check indexes before a set just so
>> that I never get an IndexOutOfBounds exception, as if I get one, then I
>> can't use the lists anymore.
>>
>> Emil
>>
>>
>> Endre Stølsvik-8 wrote:
>> >
>> > I've been wondering about this: shouldn't the beginEvent-commitEvent
>> > always be in a try-finally block? This to contain any errors as best
>> > one can? It seems to me like any error anywhere in the pipeline now
>> > will lead to an irreparably inconsistent state, while if one had
>> > try-finally, with the updates.["change"] always after the actual data
>> > change invocation method, one would get something that at least in
>> > several situations resembles a transaction with both commit and
>> > rollback semantics.
>> >
>> > This would be so that even though there are some logic errors to could
>> > come up in certain situations, the application using GL would still
>> > have a chance of being consistent after an error - of being able to
>> > recover out of errors.
>> >
>> > Endre.
>> >
>> > On Sun, Apr 26, 2009 at 11:06, Holger Brands <hbrands@...> wrote:
>> >> > Is this the expected behavior?
>> >>
>> >> Yes, with the current implementation, that's expected.
>> >> If you dive into the implementation you'll see this:
>> >>
>> >> public E set(int index, E element) {
>> >> // create the change event
>> >> updates.beginEvent();
>> >> // do the actual set
>> >> E previous = data.set(index, element);
>> >> // fire the event
>> >> updates.elementUpdated(index, previous);
>> >> updates.commitEvent();
>> >> return previous;
>> >> }
>> >>
>> >> Event delivery is guarded by calls to
>> >> ListEventAssembler.beginEvent() - start recording changes
>> >> and
>> >> ListEventAssembler.commitEvent() - propagate recorded changes
>> >>
>> >> When an uncaught exception is thrown inbetween, commitEvent()
>> >> is never called and no change events are fired.
>> >> With the next call to beginEvent() the ListEventAssembler detects,
>> >> that an event delivery is in progress leading to the
>> >> ConcurrentModificationExceptions
>> >> you observed.
>> >>
>> >> Holger
>> >>
>> >> __________________________________________________________________________
>> >> Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und
>> >> viele
>> >> ausländische Netze zum gleichen Preis!
>> >> https://produkte.web.de/webde_sms/sms
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/ConcurrentModificationException%2C-Cannot-begin-a-new-event-...---reproducible-tp23172207p23241485.html
>> Sent from the GlazedLists - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: ConcurrentModificationException, Cannot begin a new event ... - reproducible
| Free embeddable forum powered by Nabble | Forum Help |
