You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Asaf Zafran (JIRA)" <ji...@apache.org> on 2007/12/30 13:49:44 UTC
[jira] Created: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
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
[jira] Commented: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
Posted by "Vinh Nguyen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556153#action_12556153 ]
Vinh Nguyen commented on MUSE-283:
----------------------------------
SimpleNotifictionProducer.getSubscriptions() already returns an unmodifiable collection, so I don't think there's a need to wrap the result in an ArrayList.
I think the real issue is that two separate processes are attempting to access/modify the same list of subscriptions. For example, the ConcurrentModificationException could happen if a subscription expires at about the same time when an attempt is made to publish a notification to it.
The fix is probably two-fold:
1) In NotificationProducer.publish(), call subscriptionManager.publish() only if the subscriptionManager.hasBeenShutdown() returns false.
2) The caller should only invoke NotificationProducer.publish() only if NotificationProducer.hasBeenShutdown() returns false. If true, don't publish the notification. This is for cases where the caller holds a reference to a NotificationProducer but isn't aware if the producer resource itself got terminated at some point, so the caller might have a reference to an invalid NotificationProducer object.
> 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
[jira] Commented: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
Posted by "Chris Twiner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556221#action_12556221 ]
Chris Twiner commented on MUSE-283:
-----------------------------------
Unmodifiable collections only stop changes being made to them, they don't stop changes to the underlying structure from other pieces of code. Iterating on an unmodifiable is the same as iterating on the original collection. Iterating with changes is enough to throw ConcurrentModificationException which happens regardless of the shutdown state of the subscriptionManager.
Currently the implementation, sensibly I believe, uses synchronized blocks around the data structure modifcations (with the exception of this bug). This implies for most stable subscription lists there is only a small cost in making a "copy" of the subscriptions to publish on, not the entire publish function.
for example if, in the copy version:
Thread 1 Thread 2 Thread 3
addSub removeSub getSubscriptions (and use the results)
these are all ordered operations, one cannot affect the other.
If the copy is not made in getSubscriptions (as with the current svn code) the follow scenarios will fail *maybe/sometimes/possibly* :
Thread 1 Thread 2 Thread 3
addSub getSubscriptions (and use the results)
Thread 1 Thread 2 Thread 3
removeSub getSubscriptions (and use the results)
Thread 1 Thread 2 Thread 3
addSub removeSub getSubscriptions (and use the results)
as the added subscription changes the structure as well.
The only way for these scenarios to be correct and keep a high level of concurrency and is to make a copy within the getSubscriptions function. This would hold true of any other function that manipulated the subscriptions structure outside of synchronized blocks.
As mentioned above this still allows the case when a remove (or expire) receieves an update after (or during) its removeSubscription call (or expiry). This is however an acceptable tradeoff in an mt system imo.
As a side note the hasSubscription / resourceRemoved function is also at risk here (different race condition - not iterator based) from multiple remove subscription calls (handled by different threads in the resourceRemoved function). Only way to solve that is to have resourceRemoved synchronized, but thats straight forward enough.
> 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
[jira] Commented: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
Posted by "Chris Twiner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554999 ]
Chris Twiner commented on MUSE-283:
-----------------------------------
simple workaround is to add this code to a derived function.
protected synchronized Collection getSubscriptions()
{
return new ArrayList(
super.getSubscriptions() );
}
(or add the arraylist wrapper into a c+p of simplenotificationproducer).
as removed / added subscriptions during the publish won't affect the list. Only issue is that a removed subscription still recieves an event. As this is always possible due to network issues I don't see that as a big issue. Its certainly much quicker to do this than to use a Hashtable for example and receive a hit on all functions.
Note that this should still be thread safe as the same object monitor is used with the synchronized function (i believe, but couldn't find anything to the contrary).
> 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
[jira] Commented: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
Posted by "Vinh Nguyen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556290#action_12556290 ]
Vinh Nguyen commented on MUSE-283:
----------------------------------
Hi Chris,
I agree...now I understand your first comment:) So to fix this bug, the Muse code should be changed from:
protected synchronized Collection getSubscriptions() {
return Collections.unmodifiableCollection(_subscriptionsByEPR.values());
}
To:
protected synchronized Collection getSubscriptions() {
return new ArrayList(_subscriptionsByEPR.values());
}
As you pointed out, this ensures that each caller get a new list of the current subscriptions, instead of everyone getting the same list and possibly encountering the ConcurrentModificationException if the list is modified during an iteration.
But I realize now that this still doesn't fully address the race condition where a subscription expires at the same time a notification is published. So even if a caller has its own list of subscriptions, then if one of those subscriptions expired, the subscription itself doesn't prevent a notification from being published afterwards. This is incorrect behavior.
In SimpleSubscriptionManager, nothing special is done during shutdown(), so a subsequent call to its publish() method will still succeed. A fix is also needed in SimpleSubscriptionManager.publish() to first check if hasBeenShutdown() returns false immediately before calling NotificationProducerClient.notify(NotificationMessage[]).
The same issue seems to appear in SimpleNotificationProducer and possibly many other capabilities. No cleanup is done in shutdown(), so calls to any other method after shutdown() can still succeed.
A solution to this is to add "sychronized" to both shutdown() and publish(). This may not be necessary though as long as proper cleanup is done in shutdown(), and publish() and other methods do proper checks to ensure they don't do anything if shutdown() was already called.
I think to be safe in general, a caller should still check capability.hasBeenShutdown() before invoking publish() or other methods on the capability.
> 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
[jira] Resolved: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
Posted by "Chris Twiner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Twiner resolved MUSE-283.
-------------------------------
Resolution: Fixed
> 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: Chris Twiner
> Priority: Critical
> Fix For: 2.2.1
>
>
> 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
[jira] Commented: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
Posted by "Chris Twiner (JIRA)" <ji...@apache.org>.
[ 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
[jira] Assigned: (MUSE-283)
SimpleNotificationProducer.getSubscriptions() returns a not-syncronized
collection
Posted by "Chris Twiner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MUSE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Twiner reassigned MUSE-283:
---------------------------------
Assignee: Chris Twiner (was: Dan Jemiolo)
> 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: Chris Twiner
> 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