Fix issue with passing quit() to OMC in subsequent calls of OMCSessionZMQ

[ne3x7]

Hello! I ran into a strange problem, found its source and propose a quick fix. Would be very proud to contribute.

The problem occurs when executing multiple subsequent calls to create and close OMCSessionZMQ, for example subsequently creating and managing instances of ModelicaSystem in a loop.

The issue is that at second (and possibly further) repetitions sendExpression('quit()') deadlocks in self._omc.recv_string(). The reason for that, I believe, is improper impact of sendExpression('quit()') on OMC in the first repetition.

This is a quick fix to allow for desired functionality. The best way to fix this issue is to replace REP/REQ logic in ZMQ to PUSH/PULL logic, which doesn't require responses.

[CLAassistant]

All committers have signed the CLA.

[sjoelund]

First of all, the DS_Store file does not belong here. I am also a little bit unsure if the result should really be the string "Force quit" as it is different in other version of OMPython; I think returning None would be more appropriate (this is what is returned when you "don't" return in Python).

I also can't reproduce crashes, because the ZMQ connection is set to None and subsequent calls to quit() do not perform any action.

Note: Having the call to quit() do something special is a little odd to me anyway. I would have preferred to have:
with OMSessionZMQ() as om:
om.sendExpression(...)
...

Automatically closes the connection

But this is old crap...

If there would be a testcase added for this I would be happy to try to reproduce it.

[sjoelund]

I cherry-picked and fixed your commit to #67. Perhaps this fix helps with the odd behavior I saw when trying to run OMPython on our Jenkins server.

[ne3x7]

Thanks for your response. In order to reproduce the issue, prepare a “model.mo” file with a Class class in it and then run:

from OMPython import OMModel

def worker():
    m = OMModel(“model.mo”, “Class”)
    m.simulate()

for _ in range(10):
    worker()

The issue I encounter is that worker() doesn’t return the second time.

[sjoelund]

This seems to work fine on my machine with the old master. But if it is a deadlock scenario it might just be that my machine is too fast or simply not overloaded. I'll try to add this test to the new test suite.

[ne3x7]

This might be the case. I run it on a virtual machine with very limited specs.

[sjoelund]

OK, I added some tests. They don't deadlock because I have quite many fixes for weird behavior of quitting the OM process, including yours which you say fixed the problem as well.