62
81%

Ran 16 Oct 2017 06:37AM UTC

Jobs 4

Files 61

Run time 1min

Badge

Embed ▾

pending completion

Build # 62

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>

Run Details

5704 of 8507 relevant lines covered (67.05%)

2.68 hits per line

Jobs

ID	Job ID	Ran	Coverage
1	62.1	16 Oct 2017 06:37AM UTC	67.0	Travis Job 62.1
2	62.2	16 Oct 2017 06:38AM UTC	66.91	Travis Job 62.2
3	62.3	16 Oct 2017 06:38AM UTC	67.03	Travis Job 62.3
4	62.4	16 Oct 2017 06:37AM UTC	67.04	Travis Job 62.4

Source Files on build 62

Detailed source file information is not available for this build.

ICRAR / daliuge / 62
81%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Jobs

Source Files on build 62

ICRAR / daliuge / 62 81%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Jobs

Source Files on build 62

ICRAR / daliuge / 62
81%

README BADGES
x