ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Twiner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MUSE-283) SimpleNotificationProducer.getSubscriptions() returns a not-syncronized collection
Date Sat, 05 Jan 2008 23:13:34 GMT

    [ https://issues.apache.org/jira/browse/MUSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556298#action_12556298
] 

Chris Twiner commented on MUSE-283:
-----------------------------------

hiya Vinh,

Its distinctly possible to have the resource shutdown between you checking the hasBeenShutdown
and the sending of the message (in notificationclient notify).  So checking for hasBeenShutdown
in notificationproducer publish only reduces the possibility we both highlighted.

Adding a synchronized to both shutdown and publish in subscriptionmanager wouldn't remove
this fully either and it would also add a big bottleneck.  For example thread 1 calls shutdown
as thread 2 calls publish, thread 2 gets the monitor and publishes and later thread 1 gets
the monitor and shutsdown.  From the client who has destroyed the resource or from the expiry
perspective the result is the same, at first glance unexpected behaviour.

This really is no different than having a long router trip delay sending a published message
whilst the response for destroy or expiring is quicker.  There isn't really a way to guard
against it.  Of course if thats muses greatest MT problem then its in pretty good shape, but
we know that isn't the case (dom handling / epr) is far more dangerous ;-)

Having said all that I'm happy to have the check in subscriptionmanager itself (so it doesn't
pollute the notificationproducer function).

> SimpleNotificationProducer.getSubscriptions() returns a not-syncronized collection
> ----------------------------------------------------------------------------------
>
>                 Key: MUSE-283
>                 URL: https://issues.apache.org/jira/browse/MUSE-283
>             Project: Muse
>          Issue Type: Bug
>          Components: WSN NotificationProducer
>    Affects Versions: 2.2.0
>         Environment: os: unix on solaris 
>            Reporter: Asaf Zafran
>            Assignee: Dan Jemiolo
>            Priority: Critical
>
> we have extended the SimpleNotificationProducer.
> in the method 
> public void publish(QName topicName, Element[] content, EndpointReference consumer) throws
SoapFault
> we have called the method:
> Iterator i = getSubsriptions().iterator();
> and the line 
> iterator.next();
> has caused a ConcurrentModificationException.
> the stack trace is :
> java.util.ConcurrentModificationException
>       	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
>       	at java.util.HashMap$ValueIterator.next(HashMap.java:871)
>       	at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010)
>       	at com.cisco.nm.cmp.nbi.wsdm.server.notification.NotificationProducer.publish(NotificationProducer.java:182)
>       	at com.cisco.nm.cmp.nbi.wsdm.server.notification.NotificationProducer.publish(NotificationProducer.java:253)
>       	at com.cisco.nm.cmp.nbi.wsdm.server.wsresource.CommandCallback.publish(CommandCallback.java:256)
>       	at com.cisco.nm.cmp.nbi.wsdm.server.wsresource.CommandCallback.publish(CommandCallback.java:243)
>       	at com.cisco.nm.cmp.nbi.wsdm.server.wsresource.provservice.WorkflowCallback.gotResult(WorkflowCallback.java:92)
>       	at com.cisco.nm.cmp.nbi.mediator.core.CommandExecutor.setNotifyResult(CommandExecutor.java:270)
>       	at com.cisco.nm.cmp.nbi.mediator.core.MediatorOutputListener.callTranslator(MediatorOutputListener.java:379)
>       	at com.cisco.nm.cmp.nbi.wsdm.server.mediation.provisioning.workflow.run.RunWFResponseListener.notification(RunWFResponseListener.java:86)
>       	at com.cisco.nm.cmp.client.mediator.handlers.DefaultResponseHandler.handleJMSMessageObject(Unknown
Source)
>       	at com.cisco.nm.cmp.client.mediator.handlers.DefaultResponseHandler.handleJMSMessageObject(Unknown
Source)
>       	at com.cisco.nm.cmp.client.mediator.handlers.DefaultResponseHandler.handleJMSMessage(Unknown
Source)
>       	at com.cisco.nm.cmp.client.mediator.handlers.DefaultResponseHandler.handleJMSMessage(Unknown
Source)
>       	at com.cisco.nm.cmp.client.mediator.handlers.ResponseHandlerThread.run(Unknown
Source)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org


Mime
View raw message