Re: [Gnumed-bugs] <bug>: same wierd behavior?

[Karsten Hilbert]

On Mon, Dec 19, 2016 at 02:46:39PM +0100, Marc Angermann wrote:

> user comment  : same wierd behavior?
> 
> client version: 1.6.10

...

> 2016-12-19 14:38:36  ERROR     gm.person 
> (/usr/share/gnumed/Gnumed/business/gmPerson.py::get_emr() #1942): still 
> failed to acquire EMR access lock, aborting (thread [140050942101248])
> 2016-12-19 14:38:36  ERROR     gm.gui 
> (/usr/share/gnumed/Gnumed/wxpython/gmExceptionHandlingWidgets.py::handle_uncaught_exception_wx()
>  #215): enabling debug mode
> 2016-12-19 14:38:36  DEBUG     gm.gui 
> (/usr/share/gnumed/Gnumed/wxpython/gmExceptionHandlingWidgets.py::handle_uncaught_exception_wx()
>  #219): unhandled exception caught:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py", line 
> 16765, in <lambda>
>     lambda event: event.callable(*event.args, **event.kw) )
>   File "/usr/share/gnumed/Gnumed/wxpython/gmEncounterWidgets.py", line 634, 
> in __refresh
>     enc = gmPerson.gmCurrentPatient().get_emr(allow_user_interaction = 
> False).active_encounter
>   File "/usr/share/gnumed/Gnumed/business/gmPerson.py", line 1943, in get_emr
>     raise AttributeError('cannot lock access to EMR for identity [%s]' % 
> self._payload[self._idx['pk_identity']])
> AttributeError: cannot lock access to EMR for identity [5588]

What you are seeing here is the effect of a problem with
threading which manifests itself when GNUmed asks whether to
continue a fairly-recent encounter.

For 1.7 I have eventuelly implemented an entirely different
solution to the problem which should not suffer from the
threading issue entirely by design at all.

In 1.6 you _can_ circumenvent the issue by configuring the
minimum and maximum TTL of encounters to hold the same value.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346