[interchange-bugs] [rt.icdevgroup.org #340] UserTag definition cross-catalog pollution

Jon Jensen via RT interchange at rt.icdevgroup.org
Wed Jul 7 20:57:37 UTC 2010


Wed Jul 07 20:57:36 2010: Request 340 was acted upon.
Transaction: Ticket created by jon
       Queue: Interchange
     Subject: UserTag definition cross-catalog pollution
       Owner: Nobody
  Requestors: jon at endpoint.com
      Status: new
 Ticket <URL: http://rt.icdevgroup.org/Ticket/Display.html?id=340 >


Date: Wed, 07 Jul 2010 07:51:39 -0700
From: Chris Keane <chris.keane at zzgi.com>
To: interchange-users at icdevgroup.org
Subject: Re: [ic] "SOLVED" Update to update: Re: AddAttr only UserTags sometimes work, sometimes fail
Message-ID: <4C34947B.10408 at zzgi.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
	rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5

> I've turned on full debugging and uncommented quite a few of the 
> logDebug statements in Parse.pm. I'm still tracing through but is this 
> a possible scenario?
> Two catalogs, running in the same server.
>
> Each has a private catalog-specific UserTag called, say "thing". But 
> they're coded differently in how they take their similar arguments. 
> For example in catalog #1:
>
> UserTag thing Order arg
> UserTag thing AddAttr
> UserTag thing Routine << EOR
> sub {
>     ($arg, $opt) = @_;
>     ::logDebug("arg is $arg");
> }
>
>
> And in catalog #2:
> UserTag thing AddAttr
> UserTag thing Routine << EOR
> sub {
>     ($opt) = @_;
>     ::logDebug("arg is $opt->{arg}");
> }
>
> Both catalogs call the tag using [thing arg=arg_value]
>
> It looks like catalog #2's version works right up until sometime after 
> someone uses catalog #1's version. After that, Parse attempts to 
> always send a positional parameter for arg whether or not the 
> application is expecting it. In this case, the catalog #2's calls to 
> the 'thing' tag will fail with a server error. The unevaled arguments 
> to catalog #1's version should be
> ["arg_value",{'arg' => "arg_value"}]
> whereas catalog #2 should be getting
> [{'arg' => "arg_value"}]
>
> Unfortunately it seems that the per-catalog arg list is getting mixed 
> because, for example, catalog #2's version is getting the same 
> argument list as would be sent to catalog #1's version.
> Therefore, because $_[0] is a scalar rather than a hashref, any 
> subsequent calls to $opt->{arg} gives a server error since at that 
> point $opt is a scalar.
>
> Specifically, in Parse::resolve_args:
>         @list = @{$ref}{@{$Order{$tag}}};
>         push @list, $ref if defined $addAttr{$tag};
>         push @list, (shift || $ref->{body} || '') if $hasEndTag{$tag};
>         return @list;
>
> @{$Order{$tag}} has a value of ["arg"] whether called from catalog #1 
> or catalog #2. Note that when the server first starts, catalog #2 
> calls to UserTag thing show (correctly) that @{$Order{$tag}} has a 
> value of [], and it's only after calls to "thing" from catalog #1 that 
> @{$Order{$tag}} acquires the value of ["arg"] for all catalogs.
>
> Still digging but if anyone has any suggestions I'd love to hear them.


Based on the above, we went through the process of synchronizing the 
Order and AddAttr arguments for all UserTags on all catalogs in our 
system so that the arguments are identical.
A quick background: our product is a management system for racing 
organizations. We we have many catalogs running on each server that are 
mostly similar but with some commonly named catalog-specific UserTags 
that are customized for each organization.

In some rare cases we've modified the arguments to a catalog-customized 
UserTag.

It turns out that in Parse, the $Order hash doesn't keep a 
catalog-specific Order for each UserTag but that the Order is global. So 
if you have a UserTag:

UserTag goo Order arg1 arg2

in one catalog, and

UserTag goo Order arg2 arg3 arg4

in a second catalog running on the same server, the $Order hash will get 
overwritten. The behavior indicates that it will be OK until the 2nd 
version is called, thereafter the 2nd version's arguments take precedence.

Anyway, changing all the catalog-customized UserTags to have the same 
arguments seems to have solved the problem.

I'm sorry this was not a more interesting problem. After being an 
Interchange proponent for 8 years this problem had us moments away from 
ditching Interchange for a more stable and active platform.

Chris.


_______________________________________________
interchange-users mailing list
interchange-users at icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users



More information about the interchange-bugs mailing list