Re: Velocity exits foreach loop in macro unpredictably -- partial solution?

["Geir Magnusson Jr." <ge...@optonline.net>]

On 11/5/01 4:04 PM, "Nick Bauman" <ni...@cortexity.com> wrote:

> The preliminary results when caching is turned on shows a reduction in the
> number of problem transcripts that have fewer lines (from the foreach loop)
> than they should. In 10,000 iterations in our load testing environment, only
> a handful have fewer than expected events rendered.
> 

I'm skeptical.  I assume that you don't get the full output set from the
#foreach(), but you have follow-on 'stuff' from later in either *that macro*
or *that template*?

Or does the render output end abruptly after one of the elements in the
#foreach() ?

geir

> More results to come.
> 
>>> On 11/5/01 11:15 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
>> 
>>>>> 
>>>>> I'm not so sure - if he was seeing that, it would be the case that
>>>>> he saw #<macroname> in the output for each call.
>>>>> 
>>>> 
>>>> I wasn't seeing #<macroname> at all.
>>>> 
>>> 
>>> So you were seeing that the #macro() was invoked, because you got some
>>> of the items in the list, but you weren't getting through the list
>>> every time?
>> 
>> Exactly right: you are correct, sir.
>> 
>>> -- 
>>> Geir Magnusson Jr.
>>> geirm@optonline.net System and Software Consulting
>>> "He who throws mud only loses ground." - Fat Albert
>>> 
>> 
>> -Nick
>> 
>> 
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org> For additional
>> commands, e-mail: <ma...@jakarta.apache.org>
> 

-- 
Geir Magnusson Jr.                       geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Velocity exits foreach loop in macro unpredictably -- partial

["Geir Magnusson Jr." <ge...@optonline.net>]

On 11/5/01 4:20 PM, "Nick Bauman" <ni...@cortexity.com> wrote:

>> On 11/5/01 4:04 PM, "Nick Bauman" <ni...@cortexity.com> wrote:
>> 
>>> The preliminary results when caching is turned on shows a reduction in
>>> the number of problem transcripts that have fewer lines (from the
>>> foreach loop) than they should. In 10,000 iterations in our load
>>> testing environment, only a handful have fewer than expected events
>>> rendered.
>>> 
>> 
>> I'm skeptical.  I assume that you don't get the full output set from
>> the #foreach(), but you have follow-on 'stuff' from later in either
>> *that macro* or *that template*?
> 
> Correct. This is why I think it's the foreach. Mind you, I cannot make a
> contrived example do what our load testing environment is doing, which
> frustrates the hell out of me! I'm still working on it.
> 
>> 
>> Or does the render output end abruptly after one of the elements in the
>> #foreach() ?
> 
> Just to be clear, the render output DOES NOT end abruptly, only that the
> template does not render all the legally-renderable events in the meeting
> which is iterated over in the foreach loop.

That's what I thought, and that's why I am a little skeptical about the
cache issue (although who knows...).  To explain, because you rendered
'stuff' that came after the loop, and further, other parts of the template,
the bug reference earlier doesn't apply, because that is due to fast,
multithreaded cycling of the VM manager's namespaces making VM definitions
'disappear'.  You are calling every VM that you expect...

-- 
Geir Magnusson Jr.                       geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Velocity exits foreach loop in macro unpredictably -- partial

[Nick Bauman <ni...@cortexity.com>]

> On 11/5/01 4:04 PM, "Nick Bauman" <ni...@cortexity.com> wrote:
> 
>> The preliminary results when caching is turned on shows a reduction in
>> the number of problem transcripts that have fewer lines (from the
>> foreach loop) than they should. In 10,000 iterations in our load
>> testing environment, only a handful have fewer than expected events
>> rendered.
>> 
> 
> I'm skeptical.  I assume that you don't get the full output set from
> the #foreach(), but you have follow-on 'stuff' from later in either
> *that macro* or *that template*?

Correct. This is why I think it's the foreach. Mind you, I cannot make a
contrived example do what our load testing environment is doing, which
frustrates the hell out of me! I'm still working on it.

> 
> Or does the render output end abruptly after one of the elements in the
> #foreach() ?

Just to be clear, the render output DOES NOT end abruptly, only that the
template does not render all the legally-renderable events in the meeting
which is iterated over in the foreach loop.

> geir
> 
>> More results to come.
>> 
>>>> On 11/5/01 11:15 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
>>> 
>>>>>> 
>>>>>> I'm not so sure - if he was seeing that, it would be the case that
>>>>>> he saw #<macroname> in the output for each call.
>>>>>> 
>>>>> 
>>>>> I wasn't seeing #<macroname> at all.
>>>>> 
>>>> 
>>>> So you were seeing that the #macro() was invoked, because you got
>>>> some of the items in the list, but you weren't getting through the
>>>> list every time?
>>> 
>>> Exactly right: you are correct, sir.
>>> 
>>>> -- 
>>>> Geir Magnusson Jr.
>>>> geirm@optonline.net System and Software Consulting
>>>> "He who throws mud only loses ground." - Fat Albert
>>>> 
>>> 
>>> -Nick
>>> 
>>> 
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org> For additional
>>> commands, e-mail: <ma...@jakarta.apache.org>
>> 
> 
> -- 
> Geir Magnusson Jr.                       geirm@optonline.net
> System and Software Consulting
> You're going to end up getting pissed at your software
> anyway, so you might as well not pay for it. Try Open Source.
> 
> 
> 
> --
> To unsubscribe, e-mail:  
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>


-- 
Those willing to give up a little freedom for a little bread are likely to
lose both. --Sidney Crooke, American Abolitionist


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>