Association idle timer

[jayns...@gmail.com]

I ran some stress tests to verify the behavior of my DICOM SCP component when dealing will parallel associations. Here are the results:

1. If the sender errors out or does not release the association, then the scp will continue to treat this association as active. This means one less parallel association. Eventually, it is possible to fill the active associations list in AE class with "dead" associations and deny service to new valid association requests. Also, the number of threads will be high in such a scenario.

So what I need is the association to self-destruct after a (configurable) period of inactivity. I made some changes to implement this feature and I have attached the diff file to this post. Please review and let me know your thoughts. I also have the unit test for it and I can provide that if you agree with my changes. 

2. The ARTIMER is working correctly, however the threads (association and DULServiceProvider) were still hanging around after the client connection was closed. So, I introduced code to kill the DULServiceProvider loop if CheckTimer() is True and in the Association class I terminate the thread if self.DUL is not running anymore. The DULServiceProvider code is not in the diff file. I added the following line to run() in my copy of DULServiceProvider.py:

elif CheckTimer()

      self.kill = True

This causes the DULServiceProvider thread to terminate but the Association thread continues to run (despite my attempt to terminate it when self.DUL.isAlive() returns False, see diff file). I am investigating that problem, but in the meantime I would like to get your feedback on the association idle timeout feature.

3. The removal of completed associations from the active associations list in AE class is happening during iteration, which will cause items to be skipped. Try this instead:

self.Associations[:] = [active_assoc for active_assoc in self.Associations if active_assoc.isAlive()]

4. The result source is incorrectly set to 1 in AE_8() in fsm.py. Setting the source when constructing the response and removing the hardcoding fixes this defect.

[Patrice Munger]

Hi Jay,

Thank you very much for this work. I will give your changes a try against my own test suite (which is not as demanding as your own tests anyways) and integrate it to the main source tree. I will tell you more when I have a chance to review it in more details. In the meanwhile, please keep me informed of any new finding you may make.

Patrice.

[Ed McDonagh]

Hello Jay, Patrice, fellow pynetdicom users,

I have a problem whereby a long-running StoreSCP starts returning 'Local Limit Exceeded', and it seems that this might be related to the work you have done here.

I'm assuming that to make use of your changes, I need to setup the AE with 

MyAE.MaxAssociationIdleSeconds = 25

My question for this is: what would an appropriate value be? I don't want to kill a long-running store operation, but likewise I don't want to maintain zombie associations that clog up the SCP until it refuses any connections.

An associated question is whether Patrice you intended to keep the self.MaxNumberOfAssociations = 2?

Any advice would be appreciated.

Kind regards

Ed

openrem.org

[Patrice Munger]

Hello Ed, 

There is no special reason why self.MaxNumberOfAssociations was set to 2, apart that is seemed a reasonable value for a low trafic SCP. I don't see any reason not to increase it. I would only be concerned about performance drop if increased too much, because threads in python are hindered by the GIL. 

In any case, if zombie assocations are building up, it indicates a problem somewhere in the code ... 

--
You received this message because you are subscribed to the Google Groups "pynetdicom" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pynetdicom+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Patrice Munger