On 9/21/07, Steve Loughran <stevel apache.org> wrote:
> Peter Reilly wrote:
> > On 9/21/07, Steve Loughran <stevel apache.org> wrote:
> >> Peter Reilly wrote:
> >>> 1) Some of the traces seem to imply a
bug.
> >>
> >> clearly
> >>
> >>>
org.apache.tools.ant.taskdefs.Property$PropertyResolver.eval
uate(Property.java:110)
> >>> at
> >>>
org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelp
er.java:787)
> >>> - locked
<0x00002aaab4013548> (a
> >>> org.apache.tools.ant.PropertyHelper)
> >>> at
> >>>
org.apache.tools.ant.PropertyHelper.parseNextProperty(Proper
tyHelper.java:541)
> >>> at
> >>>
org.apache.tools.ant.PropertyHelper.parseProperties(Property
Helper.java:502)
> >>> at
> >>>
org.apache.tools.ant.RuntimeConfigurable.maybeConfigure(Runt
imeConfigurable.java:390)
> >>> The intent of Property.PropertyResolver is
I think to remain in
> >>> the Property task - the trace seems to
imply that it has
> >>> escaped from that task.
> >> I think it is looping. There is a per-thread
stack to detect this, but
> >> it isnt working. Otherwise the loop wouldnt
happen.
> >>
> >> This could be some wierd race condition in the
JVM itself, which may be
> >> reordering operations in the single thread.
Remember, unless your
> >> variable is tagged as volatile, or the block
is synchronized, Java can
> >> swap the order of actions. It can even reorder
volatile access in Java <1.5
> > I know, but 1) I do not know why a ThreadLocal
(shudder) is needed
> > here, this means that the code is more
complicated than it needs to be.
> > and
>
> I presume its a way of preventing recursion down the
resolution path.
> When I did something like this in some grid-standard
XML variant of the
> smartfrog language I just passed the stack down as an
explicit parameter.
>
> I dont like threadlocals as they are a way to consume
more memory than
> usual.
>
> > 2) even with the above, the clone operation should
have protected
> > the rest of the system as the tasks deletete is
only added to
> > the cloned property helper which is local to the
method.
> >
>
> makes sense
>
> > In any case, I think that the code is too slow for
a very common code
> > path in ant.
> >
>
> well, let's get it working, then worry about
performance. Actually, both
> may be the same solution. If we can move to a stack
param then the
> concurrency logic changes.
I have made a modification to the way properties are
expanded, so
hopefully this should be resolved.
Peter
>
>
> -steve
>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribe ant.apache.org
> For additional commands, e-mail: dev-help ant.apache.org
>
>
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe ant.apache.org
For additional commands, e-mail: dev-help ant.apache.org
|