Re: [Springframework-rcp-dev] concurrent modif in the multicaster

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Jan,

Thanks for your email. I've looked in more details at the javadoc of the =
AbstractApplicationEventMulticaster (the parent of =
SimpleApplicationEventMulticaster).

See =
http://www.koders.com/java/fidAA823A88FDC2F28AF66BA147B8A4E9CB9B81D98D.as=
px?s=3DgetApplicationListeners

I note the following:
 * Note that this class doesn't try to do anything clever to ensure =
thread
 * safety if listeners are added or removed at runtime. A technique such =
as
 * Copy-on-Write (Lea:137) could be used to ensure this, but the =
assumption in
 * the basic version of the class is that listeners will be added at =
application
 * configuration time and not added or removed as the application runs.

And further:
 * A custom collection class must be specified to allow for thread-safe
 * runtime registration of listeners. A good candidate for this is Doug =
Lea's
 * <code>java.util.concurrent.CopyOnWriteArraySet</code> or its non-JDK =
predecessor,
 * <code>EDU.oswego.cs.dl.util.concurrent.CopyOnWriteArraySet</code>

And it seems to be possible to have that collection class used in Spring =
RC by simply configuring it like this (for java 5):

<bean id=3D"applicationEventMulticaster" =
class=3D"org.springframework.context.event.SimpleApplicationEventMulticas=
ter">
    <property name=3D"collectionClass" =
value=3D"java.util.concurrent.CopyOnWriteArraySet"/>
</bean>

We had this ConcurrentModification issue from time to time, so we're =
going to have a go with the javadoc suggestion and I will report here =
later on if this does not fix the issue.

Kind regards,

Benoit

-------------------------------
IMPORTANT NOTICE This communication contains information that is =
considered confidential and may also be privileged . It is for the =
exclusive use of the intended recipient(s). If you are not the intended =
recipient(s) please note that any form of distribution, copying or use =
of this communication or the information in it is strictly prohibited =
and may be unlawful. If you have received this communication in error =
please return it to the sender and delete the original.

-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...] On Behalf =
Of Jan Hoskens
Sent: 11 September 2007 07:47
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] concurrent modif in the =
multicaster

The simpleApplicationEventMulticaster has a TaskExecutor property which
handles the event casting. You can opt to use a SyncTaskExecutor here to
have your events handled synchronously.=20

Besides this, the concurrentModificationException might have nothing to
do with threading. It's possible that while events are cast, one of the
listeners is changing(adding/removing) the listener list of the
multicaster.

As for the gui updating, I'm guessing your different threads do gui
updating on the EDT (as it should be). So these are already
synchronized.

Kind Regards,
Jan

On Mon, 2007-09-10 at 16:12 +0100, Benoit Xhenseval wrote:
> Hi *,
>=20
> =20
>=20
> First of all, many thanks for considering the Readony interceptor!
> That is super to have an official implementation.
>=20
> =20
>=20
> I have just experienced the following problem a couple of times:
>=20
> =20
>=20
> java.util.ConcurrentModificationException
> java.util.ConcurrentModificationException
>         at =
java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:3=
65)
>         at =
java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:376)
>         at =
org.springframework.context.event.SimpleApplicationEventMulticaster.multi=
castEvent(SimpleApplicationEventMulticaster.java:74)
>         at =
org.springframework.context.support.AbstractApplicationContext.publishEve=
nt(AbstractApplicationContext.java:246)
>         at =
net.xxxxx.gui.domain.BusinessEventConsumer$2.run(BusinessEventConsumer.ja=
va:207)
>         at =
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
>         at =
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread=
.java:242)
>         at =
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.j=
ava:163)
>         at =
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
>         at =
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
>         at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown =
Source)
>         at =
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at =
foxtrot.pumps.ConditionalEventPump.pumpEvents(ConditionalEventPump.java:9=
8)
>         at foxtrot.AbstractSyncWorker.post(AbstractSyncWorker.java:98)
>         at =
foxtrot.AbstractSyncWorker.post(AbstractSyncWorker.java:124)
>         at foxtrot.Worker.post(Worker.java:139)
>         at =
net.xxxxxx.gui.dao.AbstractRemoteDao.executeBlockingJobInBackground(Abstr=
actRemoteDao.java:89)
>=20
> =20
>=20
> My application may have more than 1 thread updating the GUI. As far as
> I can see, there is a scenario in my app where the server triggers a
> refresh on the GUI and the dispatching thread also tries to send an
> event.
>=20
> =20
>=20
> Is there any reason why the
> SimpleApplicationEventMulticaster.multicastEvent is not synchronized?
> Should it be?
>=20
> Should the synchronization be done via the
> AbstractApplicationContext.publishEvent?
>=20
> =20
>=20
> I believe that some form of synchronization is required and that it
> should be done on either classes and not on the caller since there may
> be many=E2=80=A6
>=20
> =20
>=20
> These 2 classes are in spring-context=E2=80=A6
>=20
> =20
>=20
> The BusinessEventConsumer line 207 is like this:
>=20
>         if(shouldTriggerScreenRefresh(event)) {
>=20
>             SwingUtilities.invokeLater(new Runnable() {
>=20
>                 public void run() {
>=20
>=20
> =
Application.instance().getApplicationContext().publishEvent(newClientAppE=
vent(event));
>=20
>                 }
>=20
>             });
>=20
>         }
>=20
> =20
>=20
> Suggestions welcomed=E2=80=A6
>=20
> =20
>=20
> Thanks
>=20
> =20
>=20
> Benoit.
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> -------------------------------
>=20
> IMPORTANT NOTICE This communication contains information that is
> considered confidential and may also be privileged . It is for the
> exclusive use of the intended recipient(s). If you are not the
> intended recipient(s) please note that any form of distribution,
> copying or use of this communication or the information in it is
> strictly prohibited and may be unlawful. If you have received this
> communication in error please return it to the sender and delete the
> original.
>=20
> =20
>=20
>=20
>=20
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.12/997 - Release Date:
> 09/09/2007 10:17
>=20
>=20
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ =
Springframework-rcp-dev mailing list =
Spr...@li... =
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Springframework-rcp-dev mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

No virus found in this incoming message.
Checked by AVG Free Edition.=20
Version: 7.5.485 / Virus Database: 269.13.14/999 - Release Date: =
10/09/2007 17:43
=20

No virus found in this outgoing message.
Checked by AVG Free Edition.=20
Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: =
18/09/2007 11:53
=20