3
81%
master: 81%

Ran 16 Oct 2017 06:38AM UTC

Files 61

Run time 2s

Badge

Embed ▾

Committed 16 Oct 2017 06:23AM UTC coverage: 67.027% (+0.01%) from 67.015%

Job # 62.3

Build Type

push

travis-ci

Committed by

rtobar

Commit Message

DynlibApp calling i.read/o.write directly

The previous option of holding a reference to a read/write method of the
respective object seems to be the cause of some problems we were
experiencing in multi-node deployments. By getting the read and write
attribute first and invoking it later we produce a call to __getattr__
instead of __call__, which an important distinction made by the
DropProxy class at the moment (but that we could probably work around).
By doing always a call to i.read() or o.write() we effectively call
__cal__ on the DropProxy, which is what we need to do.

This problem hasn't been picked up before because we had never actually
tried to run an DynlibApp against remote Drops (we were always using
local Drops). I will add next a unit test that mimics this behavior.
This should both confirm that this is the cause of the problem, and
ensure it doesn't happen again.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

Coverage Stats

5702 of 8507 relevant lines covered (67.03%)

0.67 hits per line

ICRAR / daliuge / 62 / 3
81%
master: 81%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 62.3

ICRAR / daliuge / 62 / 3 81% master: 81%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 62.3

ICRAR / daliuge / 62 / 3
81%
master: 81%

README BADGES
x