You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gitbox@activemq.apache.org by GitBox <gi...@apache.org> on 2019/07/12 07:39:07 UTC

[GitHub] [activemq-nms-amqp] HavretGC commented on a change in pull request #4: AMQNET-589: Failover implementation

HavretGC commented on a change in pull request #4: AMQNET-589: Failover implementation
URL: https://github.com/apache/activemq-nms-amqp/pull/4#discussion_r302862211
 
 

 ##########
 File path: src/NMS.AMQP/SessionDispatcher.cs
 ##########
 @@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+using System.Threading;
+using System.Threading.Tasks;
+using System.Threading.Tasks.Dataflow;
+
+namespace Apache.NMS.AMQP
+{
+    internal class SessionDispatcher
+    {
+        private readonly ActionBlock<NmsMessageConsumer.MessageDeliveryTask> actionBlock;
+        private int dispatchThreadId;
+        private readonly CancellationTokenSource cts;
+
+        public SessionDispatcher()
+        {
+            cts = new CancellationTokenSource();
+            actionBlock = new ActionBlock<NmsMessageConsumer.MessageDeliveryTask>(HandleTask, new ExecutionDataflowBlockOptions
+            {
+                EnsureOrdered = true,
+                MaxDegreeOfParallelism = 1,
+                CancellationToken = cts.Token
+            });
+        }
+
+        public void Post(NmsMessageConsumer.MessageDeliveryTask task) => actionBlock.Post(task);
+
+        public bool IsOnDeliveryThread() => dispatchThreadId == Thread.CurrentThread.ManagedThreadId;
+
+        private void HandleTask(NmsMessageConsumer.MessageDeliveryTask messageDeliveryTask)
+        {
+            try
+            {
+                dispatchThreadId = Thread.CurrentThread.ManagedThreadId;
+                messageDeliveryTask.DeliverNextPending();
+            }
+            finally
+            {
+                dispatchThreadId = -1;
+            }
+        }
+
+        public void Stop()
+        {
+            actionBlock.Complete();
+            cts.Cancel();
 
 Review comment:
   Hi,
   I had to resign from this, in order to implement Session recovery the same way as it was implemented in qpid jms.
   
   ```
   public void Recover()
   {
       CheckClosed();
   
       bool wasStarted = IsStarted;
       Stop();
       
       Connection.Recover(SessionInfo.Id).ConfigureAwait(false).GetAwaiter().GetResult();
   
       if (wasStarted) 
           Start();
   }
   
   ```
   
   Proposed solution made ```SessionDispatcher``` Stop method blocking despite the fact it was called from the same thread or not. As you pointed out previously, for scenarios like Connection Stop or Connection Cancel this is the desired behavior. Unfortunately for whatever reason qpid implementation of Session Recovery involves stopping session before recovery proces begins and starting it afterwords. Jms specs doesn't forbid you from calling session recover inside consumer's callback. 
   
   There is even a test case covering this scenario. --> https://github.com/apache/activemq-nms-amqp/pull/4/files#diff-8ac504bafc77c0c2adca1d0e58a87dc9R648
   
   Unfortunately doing so resulted in deadlock. After discussing this issue with @michaelandrepearce we decided to guarantee connection cancelling and stopping by using locks inside connection consumer. This way both scenarios are fully supported. 
   
   The only drawback I see there is the scenario, when you have multiple sessions running asynchronous consumers.  The second consumer will be processing messages until the first fully stops. But this is the how qpid jms is operating so I suppose it is the acceptable sacrifice. 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services