Wednesday, October 2, 2019

Move callbacks out of the kernel

I moved callback management into a separate module lino.core.callbacks. One benefit is that the code is better organized. But the main goal (if my hopes are true) is that it now works also when running under nginx with multiple threads (#3228). This might work because the kernel is being instantiated during a reentrant thread lock (threading.RLock()), which means that callbacks were not shared accross threads. My hope is rather vague because I don’t yet really understand all differences between multiprocessing and multithreading, but it is worth a try.

Before publishing this I wanted to test it also under nginx. That is I install a getlino production server on my machine. I learned that the installation instructions for a production server didn’t work. The env PATH=$PATH is needed to work around the controversial Debian feature of overriding the PATH for security reasons (source).

The main goal isn’t reached: when I run a Lino site under nginx with multiple worker processes, I still get the original problem: cannot delete e.g. calendar events because Lino asks for confirmation, and if I answer OK, Lino says “unknown callback”.

Two quotes from How to use python multiprocessing module in django view:

“Though using Celery may seem an overkill, it is a well-known way of doing asynchronous tasks. Essentially Django serves WSGI request-response cycle which knows nothing of multiprocessing or background tasks.” (Zaur Nasibov 2016-02-29)

“It really depends on the response time you want. You could have your server respond immediately after spawning Celery tasks, or you can do multiprocessing and then it will still take some time. Don’t bother with multiprocessing though, I suggest using the excellent joblib library.” (Flavian Hautbois 2016-02-29)

It seems that joblib isn’t what we need.

I started reading about Celery: https://docs.celeryproject.org/en/latest/django/first-steps-with-django.html

First success with RetrieveTIGroups-v2.wsdl

I continued working on #2779.

It seems that our WSDL file (/cbss/WSDL/RetrieveTIGroups-v2.wsdl) was simply using an invalid soap:address location. See the commit

Now the connection seems to work. And I get a new error message:

File ".../lino_welfare/modlib/cbss/tx25.py", line 1313, in get_data_rows
  reply_has_result(reply)
File ".../lino_welfare/modlib/cbss/models.py", line 401, in reply_has_result
  for i in reply.status.information:
AttributeError: 'StatusType' object has no attribute 'information'

The StatusType is defined in be/fgov/kszbcss/types/common/CommonV3.xsd as follows:

    <xsd:complexType name="StatusType">
            <xsd:sequence>
...
<xsd:element name="information" type="tns:InformationType" minOccurs="0" maxOccurs="15"/>
            </xsd:sequence>
    </xsd:complexType>

I guess that maybe suds has changed to no longer create an attribute for an empty list. Or something in the XSD or the service has changed. Anyway, by adding a test if hasattr(reply.status, ‘information’), I finally get our first successful communication with the CBSS after more than half a year of waiting:

CBSS error MSG00012: value : NO_RESULT code : MSG00012 description : The SSIN is
not sufficiently integrated for your organization

The error itself is normal since I am trying to get data about a person who is not “integrated”, i.e. being registered as a client of this PCSW.