Mailing-List: contact user-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@uima.apache.org
From: Mario Juric <mj@unsilo.ai>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_6F3710E8-A0F0-4757-B932-195123FFC2ED"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Erratic block variable behaviour in Ruta
Date: Mon, 6 Nov 2017 18:26:48 +0100
References: <39C4E2C4-206C-4610-BB8B-9DCE8DFB99A6@unsilo.ai>
 <3cf9b963-fd1d-5beb-c32e-d6961c2ae569@averbis.com>
To: user@uima.apache.org
In-Reply-To: <3cf9b963-fd1d-5beb-c32e-d6961c2ae569@averbis.com>
Message-Id: <E294208F-A5AF-42F2-A8F2-4B76748FCE34@unsilo.ai>
archived-at: Mon, 06 Nov 2017 17:26:58 -0000

--Apple-Mail=_6F3710E8-A0F0-4757-B932-195123FFC2ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Peter,

Thanks for the explanation, and no problem with the delayed respone. =
I=E2=80=99ll let you know about our outcome of the change as soon as =
possible, but I have the feeling that your suggestion will probably work =
as expected.

Best
Mario


> On 6 Nov 2017, at 17:01 , Peter Kl=C3=BCgl <peter.kluegl@averbis.com> =
wrote:
>=20
> Hi Mario,
>=20
>=20
> sorry for the delayed response... I was travelling.
>=20
>=20
> First of all, there should be no multithreading issues in ruta (in
> normal usage), at least, I am quite confident about that.
>=20
>=20
> My first guess would be that the problem is caused by the nature of
> variables and their initialization in ruta.
>=20
> The initialization of variables with values (e.g., BOOLEAN ignore =3D
> false;) does not reset its actual value during a loop like BLOCK as =
the
> variables are declared only once and because they are always global. =
The
> value only defines the initial value of the variable to which it is
> reset when the complete environment is reset (e.g., different CAS). =
The
> declaration is actually ignored in the execution of the block.
>=20
> So, you need to reset the value to false for each iteration in BLOCK. =
I
> wonder if your solution with the ASSIGN in the head rule of the block
> will work. The rule is applied in order to get a list of annotations
> (windows for the block), and so the action is already applied before =
the
> actual iteration starts.
>=20
> Could you try something like that:
>=20
>=20
> BLOCK(ForEach) EnclosingAnnotation.property=3D=3D=E2=80=9Csomething" =
{} {
>     BOOLEAN ignore =3D false;
>     ASSIGN(ignore, false);
>     EnclosedAnnotation.property=3D=3D=E2=80=9Csomething =
else"{FEATURE("value",
> =E2=80=9Cignorable") -> ASSIGN(ignore, true)};
>     EnclosingAnnotation.name=3D=3D=E2=80=9CHello"{IF(ignore =3D=3D =
false) ->
> CREATE(AnotherAnnotation, =E2=80=9Cname" =3D =E2=80=9CWorld")};
> }
>=20
>=20
>=20
> Best,
>=20
> Peter
>=20
>=20
> Am 29.10.2017 um 17:49 schrieb Mario Juric:
>> Hi Peter,
>>=20
>> We encountered a problem with a Ruta rule behaving erratically in a =
multithreaded environment. We isolated the problem to the following rule =
shown in pseudo form:
>> BLOCK(ForEach) EnclosingAnnotation.property=3D=3D=E2=80=9Csomething" =
{} {
>>    BOOLEAN ignore =3D false;
>>    EnclosedAnnotation.property=3D=3D=E2=80=9Csomething =
else"{FEATURE("value", =E2=80=9Cignorable") -> ASSIGN(ignore, true)};
>>    EnclosingAnnotation.name=3D=3D=E2=80=9CHello"{IF(ignore =3D=3D =
false) -> CREATE(AnotherAnnotation, =E2=80=9Cname" =3D =E2=80=9CWorld")};
>> }
>> We identified about 1000 documents where =E2=80=9CAnotherAnnotation=E2=80=
=9D above should be created, and we reprocessed them several times on =
EC2 using Oracle JDK build 1.8.0_151
>> with both Ruta 2.5 and UIMA 2.9 as well as Ruta 2.6.1 and UIMA =
2.10.1. The number of inconsistencies in rule firing over many runs of =
the 1K appears erratic between approximately 16% down to approximately =
0,5%, but there was always inconsistencies in every run. Removing the =
ignore condition made of course the issue disappear entirely, e.g.
>>=20
>> BLOCK(ForEach) EnclosingAnnotation.property=3D=3D=E2=80=9Csomething" =
{} {
>>    EnclosingAnnotation.name=3D=3D=E2=80=9CHello"{ -> =
CREATE(AnotherAnnotation, =E2=80=9Cname" =3D =E2=80=9CWorld")};
>> }
>> We haven=E2=80=99t experienced the issue in a single threaded =
environment yet, but we are not entirely sure whether it is related to =
multithreading, although the nature of the problem could point in the =
direction of some thread-safety issues around shared data inside Ruta, =
but that is just guessing. However, the workaround in our case was too =
rewrite the rule as follows:
>> BOOLEAN ignore =3D false;
>> BLOCK(ForEach) EnclosingAnnotation.property=3D=3D=E2=80=9Csomething" =
{-> ASSIGN(ignore, false)} {
>>    EnclosedAnnotation.property=3D=3D=E2=80=9Csomething =
else"{FEATURE("value", =E2=80=9Cignorable") -> ASSIGN(ignore, true)};
>>    EnclosingAnnotation.name=3D=3D=E2=80=9CHello"{IF(ignore =3D=3D =
false) -> CREATE(AnotherAnnotation, =E2=80=9Cname" =3D =E2=80=9CWorld")};
>> }
>> I assume the BLOCK(ForEach) action happen for every occurrence, but I =
haven=E2=80=99t actually verified that yet since there is usually only =
one occurrence in this particular case, but I was hoping you might be =
able to shed some light on this, and the problems we experienced with =
the variable declaration inside the block.
>>=20
>> Thanks
>> Mario
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>=20


--Apple-Mail=_6F3710E8-A0F0-4757-B932-195123FFC2ED--