gnumed-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-bugs] <bug>: Continue consultation


From: Karsten Hilbert
Subject: Re: [Gnumed-bugs] <bug>: Continue consultation
Date: Wed, 20 Jul 2016 22:59:45 +0200
User-agent: Mutt/1.6.0 (2016-04-01)

Hi Marc,

thanks for reporting this problem.

> user comment  : Continue consultation
> 
> client version: 1.6.7

What you are seeing is GNUmed protecting itself against
display of stale data:

> 2016-07-20 18:34:22  ERROR     gm.person 
> (/usr/share/gnumed/Gnumed/business/gmPerson.py::get_emr() #1915): still 
> failed to acquire EMR access lock, aborting (thread 139988314220288)
> 2016-07-20 18:34:22  ERROR     gm.gui 
> (/usr/share/gnumed/Gnumed/wxpython/gmExceptionHandlingWidgets.py::handle_uncaught_exception_wx()
>  #215): enabling debug mode
> 2016-07-20 18:34:22  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 
> 16763, in <lambda>
>     lambda event: event.callable(*event.args, **event.kw) )
>   File "/usr/share/gnumed/Gnumed/wxpython/gmEncounterWidgets.py", line 626, 
> in refresh
>     enc = pat.get_emr().active_encounter
>   File "/usr/share/gnumed/Gnumed/business/gmPerson.py", line 1916, 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 [%s]', 4934)

It seems you were activating a patient which which recently
active and GNUmed asked whether to continue the previous
encounter because it isn't so far back in time:

> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>           msg =  L. A.  [#4934]
> 
> Diese Karteikarte wurde erst k??rzlich bearbeitet:
> 
>   in Praxis: heute 16:43 - 16:44 ??administrative;?? @Praxis
>  BE: administrative;
> 
> Wollen Sie diese Konsultation fortsetzen ?
>  (wenn nicht, wird eine neue Konsultation begonnen)

In fact, it was just two hours ago.

How, during that supposedly modal dialog (or too fast after
the dialog was dismissed) GNUmed tries to update its display
of the active encounter at the top right:

> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #195): >>> 
> execution frame [ShowModal] in 
> [/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_windows.py] at line 805 <<<
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>          args = (<wx._windows.MessageDialog; proxy of <Swig Object of type 
> 'wxMessageDialog *' at 0x3dac6a0> >,)
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>        kwargs = {}
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #195): >>> 
> execution frame [<lambda>] in 
> [/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py] at line 16763 <<<
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>         event = <wx._core.PyEvent; proxy of <Swig Object of type 'wxPyEvent 
> *' at 0x3e31280> >
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #195): >>> 
> execution frame [refresh] in 
> [/usr/share/gnumed/Gnumed/wxpython/gmEncounterWidgets.py] at line 626 <<<
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>          self = <Gnumed.wxpython.gmEncounterWidgets.cActiveEncounterPnl; 
> proxy of <Swig Object of type 'wxPanel *' at 0x2282800> >
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>           pat = <Gnumed.business.gmPerson.gmCurrentPatient object at 
> 0x7f517fc75dd0>

Which however, needs to go look for the active encounter in
the EMR of the patient getting which fails:

> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #195): >>> 
> execution frame [get_emr] in [/usr/share/gnumed/Gnumed/business/gmPerson.py] 
> at line 1916 <<<
...
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>      got_lock = False
> 2016-07-20 18:34:22  DEBUG     gm.logging 
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #210):        
>           idx = 99

I have made that encounter display update itself "slightly
later" such that this race condition should not happen
anymore.

Please test with the attached file.

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

Attachment: gmEncounterWidgets.py
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]