You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Nick Bauman <ni...@cortexity.com> on 2001/11/05 16:25:15 UTC
Velocity exits foreach loop in macro unpredictably, both 1.1 and 1.2-dev
Forgive me my inability to come up with a consise example of how to
reproduce the error, if I had one I probably could have fixed it myself. I
can't force this to reproduce itself except under our load testing
environment at my company. I'm now working to consisely reproduce the
problem in another contrived situation. I'm asking the community if anything
I'm showing "rings a bell" to a problem.
We use Velocity as a mail templating system. We recently discovered that in
thousands of requests over a period of 5 minutes, the resulting merge()
calls yield mysteriously incomplete emails. No exceptions are thrown,
everything appears fine in the logs.
Our typical template looks like this:
-----8<-----
#* $Id: Texten_msftrxbx.vtl,v 1.1 2001/11/05 15:06:40 hvanlaar Exp $ *#
#parse ( "functions.vtl" )
$queue.getEmailSubject()
Thank you for using Acme Center. Below is a copy of your chat session
transcript for reference.
Topic: $!meeting.getTopic()
#drawStandardTextTranscript( $meeting )
==========
$!repId:$meeting.getMeetingId()
-----8<-----
the parsed template, entitled "functions.vtl" looks like this:
-----8<-----
...[other stuff]...
#macro( drawStandardTextTranscript $meeting )
#foreach( $event in $meeting.getAllEvents() )
#set( $yapper = $meeting.getParticipation($event.getFromId()) )
#if( $event.getClass().getName().equals($urlEvent) )
$yapper.getName(): $event.getStoredData()
#elseif( $event.getClass().getName().equals($chatEvent) )
#if($repRole.equals($yapper.getRole()) )
#set( $repId = $yapper.getParticipantId() )
#end
$yapper.getName(): $event.getStoredData()
#end
#end
#end
...[other stuff]...
-----8<-----
The problem is the resulting output ocassionally (5-25% of the time) will
not contain all $event.getStoredData() that it should. However, all the
other stuff in the template will look fine: the footer and everything else.
So, for some of the mails, there should be 15 lines of text, but we only see
one or two. It's very strange and I cannot reproduce it outside of our load
environment.
Question is: is it possible some wierd threading behavior is ocurring? I'm
not reusing a new VelocityContext for each call to merge() I'm making a new
one each time. All other settings in Velocity are default except the
template root, which I define.
Thanks for any insights.
--
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
Posted by "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
Posted by 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>
Re: Velocity exits foreach loop in macro unpredictably -- partial
solution?
Posted by "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>
Velocity exits foreach loop in macro unpredictably -- partial solution?
Posted by Nick Bauman <ni...@cortexity.com>.
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.
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>
--
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>
Re: Velocity exits foreach loop in macro unpredictably,
Posted by Nick Bauman <ni...@cortexity.com>.
> 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>
Re: Velocity exits foreach loop in macro unpredictably,
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/5/01 11:15 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
>> Nick,
>>
>> This bug may be related to your problem.
>>
>> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4483>.
>>
>> Bottom line: Make sure that template caching is on in production if it
>> is not. You may have to play with macros inline local scope setting
>> too.
>>
>> -Peter
>
> When I fooled with the inline stuff I got wierd results because I was
> reusing the same VelocityContext.java. I now make a new VelocityContext for
> each merge(), so maybe I can turn that on again. It's worth a try???
>
> Thanks, and I'll give caching a try too and report back.
>
>>
>> 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?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
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,
Posted by Nick Bauman <ni...@cortexity.com>.
> Nick,
>
> This bug may be related to your problem.
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4483>.
>
> Bottom line: Make sure that template caching is on in production if it
> is not. You may have to play with macros inline local scope setting
> too.
>
> -Peter
When I fooled with the inline stuff I got wierd results because I was
reusing the same VelocityContext.java. I now make a new VelocityContext for
each merge(), so maybe I can turn that on again. It's worth a try???
Thanks, and I'll give caching a try too and report back.
>
> 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.
> --
> 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>
Re: Velocity exits foreach loop in macro unpredictably,
both 1.1 and 1.2-dev
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/5/01 12:06 PM, "Peter Lynch" <pe...@mindspring.com> wrote:
> Nick,
>
> This bug may be related to your problem.
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4483>.
>
> Bottom line: Make sure that template caching is on in production if it is
> not. You may have to play with macros inline local scope setting too.
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.
>
> -Peter
>
> ----- Original Message -----
> From: "Nick Bauman" <ni...@cortexity.com>
> To: <ve...@jakarta.apache.org>
> Sent: Monday, November 05, 2001 7:25 AM
> Subject: Velocity exits foreach loop in macro unpredictably, both 1.1 and
> 1.2-dev
>
>
>> Forgive me my inability to come up with a consise example of how to
>> reproduce the error, if I had one I probably could have fixed it myself. I
>> can't force this to reproduce itself except under our load testing
>> environment at my company. I'm now working to consisely reproduce the
>> problem in another contrived situation. I'm asking the community if
> anything
>> I'm showing "rings a bell" to a problem.
>>
>> We use Velocity as a mail templating system. We recently discovered that
> in
>> thousands of requests over a period of 5 minutes, the resulting merge()
>> calls yield mysteriously incomplete emails. No exceptions are thrown,
>> everything appears fine in the logs.
>>
>> Our typical template looks like this:
>>
>> -----8<-----
>>
>> #* $Id: Texten_msftrxbx.vtl,v 1.1 2001/11/05 15:06:40 hvanlaar Exp $ *#
>> #parse ( "functions.vtl" )
>>
>> $queue.getEmailSubject()
>>
>> Thank you for using Acme Center. Below is a copy of your chat session
>> transcript for reference.
>>
>> Topic: $!meeting.getTopic()
>>
>> #drawStandardTextTranscript( $meeting )
>>
>> ==========
>> $!repId:$meeting.getMeetingId()
>>
>> -----8<-----
>>
>> the parsed template, entitled "functions.vtl" looks like this:
>>
>> -----8<-----
>>
>> ...[other stuff]...
>>
>> #macro( drawStandardTextTranscript $meeting )
>> #foreach( $event in $meeting.getAllEvents() )
>> #set( $yapper = $meeting.getParticipation($event.getFromId()) )
>> #if( $event.getClass().getName().equals($urlEvent) )
>> $yapper.getName(): $event.getStoredData()
>> #elseif( $event.getClass().getName().equals($chatEvent) )
>> #if($repRole.equals($yapper.getRole()) )
>> #set( $repId = $yapper.getParticipantId() )
>> #end
>> $yapper.getName(): $event.getStoredData()
>> #end
>> #end
>> #end
>>
>> ...[other stuff]...
>>
>> -----8<-----
>>
>> The problem is the resulting output ocassionally (5-25% of the time) will
>> not contain all $event.getStoredData() that it should. However, all the
>> other stuff in the template will look fine: the footer and everything
> else.
>> So, for some of the mails, there should be 15 lines of text, but we only
> see
>> one or two. It's very strange and I cannot reproduce it outside of our
> load
>> environment.
>>
>> Question is: is it possible some wierd threading behavior is ocurring? I'm
>> not reusing a new VelocityContext for each call to merge() I'm making a
> new
>> one each time. All other settings in Velocity are default except the
>> template root, which I define.
>>
>> Thanks for any insights.
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>
>
> --
> 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
"He who throws mud only loses ground." - Fat Albert
--
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, both 1.1 and 1.2-dev
Posted by Peter Lynch <pe...@mindspring.com>.
Nick,
This bug may be related to your problem.
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4483>.
Bottom line: Make sure that template caching is on in production if it is
not. You may have to play with macros inline local scope setting too.
-Peter
----- Original Message -----
From: "Nick Bauman" <ni...@cortexity.com>
To: <ve...@jakarta.apache.org>
Sent: Monday, November 05, 2001 7:25 AM
Subject: Velocity exits foreach loop in macro unpredictably, both 1.1 and
1.2-dev
> Forgive me my inability to come up with a consise example of how to
> reproduce the error, if I had one I probably could have fixed it myself. I
> can't force this to reproduce itself except under our load testing
> environment at my company. I'm now working to consisely reproduce the
> problem in another contrived situation. I'm asking the community if
anything
> I'm showing "rings a bell" to a problem.
>
> We use Velocity as a mail templating system. We recently discovered that
in
> thousands of requests over a period of 5 minutes, the resulting merge()
> calls yield mysteriously incomplete emails. No exceptions are thrown,
> everything appears fine in the logs.
>
> Our typical template looks like this:
>
> -----8<-----
>
> #* $Id: Texten_msftrxbx.vtl,v 1.1 2001/11/05 15:06:40 hvanlaar Exp $ *#
> #parse ( "functions.vtl" )
>
> $queue.getEmailSubject()
>
> Thank you for using Acme Center. Below is a copy of your chat session
> transcript for reference.
>
> Topic: $!meeting.getTopic()
>
> #drawStandardTextTranscript( $meeting )
>
> ==========
> $!repId:$meeting.getMeetingId()
>
> -----8<-----
>
> the parsed template, entitled "functions.vtl" looks like this:
>
> -----8<-----
>
> ...[other stuff]...
>
> #macro( drawStandardTextTranscript $meeting )
> #foreach( $event in $meeting.getAllEvents() )
> #set( $yapper = $meeting.getParticipation($event.getFromId()) )
> #if( $event.getClass().getName().equals($urlEvent) )
> $yapper.getName(): $event.getStoredData()
> #elseif( $event.getClass().getName().equals($chatEvent) )
> #if($repRole.equals($yapper.getRole()) )
> #set( $repId = $yapper.getParticipantId() )
> #end
> $yapper.getName(): $event.getStoredData()
> #end
> #end
> #end
>
> ...[other stuff]...
>
> -----8<-----
>
> The problem is the resulting output ocassionally (5-25% of the time) will
> not contain all $event.getStoredData() that it should. However, all the
> other stuff in the template will look fine: the footer and everything
else.
> So, for some of the mails, there should be 15 lines of text, but we only
see
> one or two. It's very strange and I cannot reproduce it outside of our
load
> environment.
>
> Question is: is it possible some wierd threading behavior is ocurring? I'm
> not reusing a new VelocityContext for each call to merge() I'm making a
new
> one each time. All other settings in Velocity are default except the
> template root, which I define.
>
> Thanks for any insights.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
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,
Posted by Nick Bauman <ni...@cortexity.com>.
> Code good!
>
> What I am wondering is if when one thread is iterating through the
> collection gotten from
That's verboten in our system right now. It's supposed to be that a meeting
state determines when its transcript gets mailed to the participants. When
the state is "wrapped", no new events are allowed to enter the meeting. All
of my tests show that this is indeed true. But considering that the system
is over 700 classes with more than 125,000 lines of code, I may have missed
something.
>
> #macro( drawStandardTextTranscript $meeting )
> #foreach( $event in $meeting.getAllEvents() )
>
> is another thread is modifying the collection, screwing up the
> iterator?
>
> That's why I asked about what the getAllEvents() returns...
>
> geir
>
>
> On 11/5/01 11:06 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
>
>> Geir,
>>
>> One of the events in question implements an interface and extends an
>> abstract class. I will have to show you that interface and one
>> abstract impl and two concrete implementations for it I'm interested
>> in. Sorry for posting all this code, I can't think of another way to
>> disclose the problem more consisely at the moment. Here is the
>> Interface:
>>
>> -----8<-----
>>
>> package com.webhelp.emeeting.events;
>>
>> import java.util.Date;
>>
>> /**
>> * IMeetingStoredEvent inteface.
>> * This interface defines what it means to be an event that is
>> persisted. */
>> public interface IMeetingStoredEvent extends IMeetingEvent {
>> static final long serialVersionUID = 9051789928189891274L;
>>
>> /**
>> * Return the data in a format that is safe to be persisted. <br>
>> * NOTE: This must be xml safe (ie. base 64)
>> */
>> public String getStoredData();
>>
>> /**
>> * Build up the event's data using the stored data.
>> */
>> public void setStoredData(String storedData);
>>
>> /**
>> * Return the date that the event occured
>> */
>> public Date getDate();
>>
>> /**
>> * Set the event's date
>> */
>> public void setDate(Date date);
>> }
>>
>> -----8<-----
>>
>> This is $chatEvent symbol:
>>
>> -----8<-----
>>
>> package com.webhelp.emeeting.events;
>>
>> import com.webhelp.emeeting.IMeeting;
>> import java.util.Date;
>>
>> /**
>> * ChatPublicEvent object.
>> * This event is fire when a public (ie. everyone receives) text chat
>> message occurs
>> * in a meeting.
>> */
>> public class ChatPublicEvent extends ChatEvent {
>> static final long serialVersionUID = 3612741022664978850L;
>>
>> /**
>> * Constructor that only takes our source (Used by the database layer
>> to
>> recreate object)
>> */
>> public ChatPublicEvent(IMeeting source) {
>> super(source);
>> }
>>
>> /**
>> * Constructor that takes the source and the chat messages
>> */
>> public ChatPublicEvent(IMeeting source, String chatMessage) {
>> super(source, chatMessage);
>> }
>>
>> }
>> -----8<-----
>>
>> Which extends:
>>
>> -----8<-----
>>
>> package com.webhelp.emeeting.events;
>>
>> import com.webhelp.emeeting.IMeeting;
>> import java.util.Date;
>>
>> /**
>> * ChatEvent object.
>> * This is the base class for all chat (ie. text message) events. * The
>> source is a Meeting object. <br>
>> * NOTE: This is a stored event.
>> */
>> public abstract class ChatEvent extends MeetingAppEvent implements
>> IMeetingStoredEvent {
>> static final long serialVersionUID = -6825658304993031299L;
>>
>> /**
>> * This is our chat message.
>> */
>> private String chatMessage = null;
>>
>> /**
>> * The event date
>> */
>> private Date date;
>>
>> /**
>> * Constructor that only takes our source (Used by the database layer
>> to
>> recreate object)
>> */
>> public ChatEvent(IMeeting source) {
>> super(source);
>> // Note: The database layer sets the date when rebuilding
>> }
>>
>> /**
>> * Constructor that takes the source and the chat messages (Standard
>> constructor)
>> */
>> public ChatEvent(IMeeting source, String chatMessage) {
>> super(source);
>>
>> this.chatMessage = chatMessage;
>> this.date = new Date(System.currentTimeMillis());
>> }
>>
>> /**
>> * Get our chat message
>> */
>> public String getChatMessage() {
>> return this.chatMessage;
>> }
>>
>> /**
>> * Return the data in a format that is safe to be persisted. <br>
>> * NOTE: This must be xml safe (ie. base 64)
>> */
>> public String getStoredData() {
>> return this.chatMessage;
>> }
>>
>> /**
>> * Build up the event's data using the stored data.
>> */
>> public void setStoredData(String storedData) {
>> this.chatMessage = storedData;
>> }
>>
>> /**
>> * set when this bad boy was made
>> */
>> public void setDate(Date date) {
>> this.date = date;
>> }
>>
>> /**
>> * get when this was made
>> */
>> public Date getDate() {
>> return this.date;
>> }
>>
>> /**
>> * Method declaration
>> * @return
>> */
>> public String toString() {
>> return super.toString() + ", msg=" + this.chatMessage;
>> }
>>
>> }
>>
>> -----8<-----
>>
>>> On 11/5/01 10:25 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
>>>
>>>> Forgive me my inability to come up with a consise example of how to
>>>> reproduce the error, if I had one I probably could have fixed it
>>>> myself. I can't force this to reproduce itself except under our load
>>>> testing environment at my company. I'm now working to consisely
>>>> reproduce the problem in another contrived situation. I'm asking the
>>>> community if anything I'm showing "rings a bell" to a problem.
>>>>
>>>> We use Velocity as a mail templating system. We recently discovered
>>>> that in thousands of requests over a period of 5 minutes, the
>>>> resulting merge() calls yield mysteriously incomplete emails. No
>>>> exceptions are thrown, everything appears fine in the logs.
>>>>
>>>> Our typical template looks like this:
>>>>
>>>> -----8<-----
>>>>
>>>> #* $Id: Texten_msftrxbx.vtl,v 1.1 2001/11/05 15:06:40 hvanlaar Exp $
>>>> *# #parse ( "functions.vtl" )
>>>>
>>>> $queue.getEmailSubject()
>>>>
>>>> Thank you for using Acme Center. Below is a copy of your chat
>>>> session transcript for reference.
>>>>
>>>> Topic: $!meeting.getTopic()
>>>>
>>>> #drawStandardTextTranscript( $meeting )
>>>>
>>>> ==========
>>>> $!repId:$meeting.getMeetingId()
>>>>
>>>> -----8<-----
>>>>
>>>> the parsed template, entitled "functions.vtl" looks like this:
>>>>
>>>> -----8<-----
>>>>
>>>> ...[other stuff]...
>>>>
>>>> #macro( drawStandardTextTranscript $meeting )
>>>> #foreach( $event in $meeting.getAllEvents() )
>>>> #set( $yapper = $meeting.getParticipation($event.getFromId()) ) #if(
>>>> $event.getClass().getName().equals($urlEvent) )
>>>> $yapper.getName(): $event.getStoredData()
>>>> #elseif( $event.getClass().getName().equals($chatEvent) )
>>>> #if($repRole.equals($yapper.getRole()) )
>>>> #set( $repId = $yapper.getParticipantId() )
>>>> #end
>>>> $yapper.getName(): $event.getStoredData()
>>>> #end
>>>> #end
>>>> #end
>>>>
>>>> ...[other stuff]...
>>>>
>>>> -----8<-----
>>>>
>>>> The problem is the resulting output ocassionally (5-25% of the time)
>>>> will not contain all $event.getStoredData() that it should. However,
>>>> all the other stuff in the template will look fine: the footer and
>>>> everything else. So, for some of the mails, there should be 15 lines
>>>> of text, but we only see one or two. It's very strange and I cannot
>>>> reproduce it outside of our load environment.
>>>>
>>>> Question is: is it possible some wierd threading behavior is
>>>> ocurring? I'm not reusing a new VelocityContext for each call to
>>>> merge() I'm making a new one each time. All other settings in
>>>> Velocity are default except the template root, which I define.
>>>>
>>>> Thanks for any insights.
>>>
>>> Yeek :) We'll find it...
>>>
>>> 1) What version of Velocity?
>>>
>>> 2) what is the Class returned from '$meeting.getAllEvents()'?
>>>
>>> --
>>> Geir Magnusson Jr.
>>> geirm@optonline.net System and Software Consulting
>>> "They that can give up essential liberty to obtain a little temporary
>>> safety deserve neither liberty nor safety." - Benjamin Franklin
>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org> For additional
>>> commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>
>> --
>> 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
> "Whoever would overthrow the liberty of a nation must begin by subduing
> the freeness of speech." - Benjamin Franklin
>
>
>
> --
> 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>
Re: Velocity exits foreach loop in macro unpredictably,
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Code good!
What I am wondering is if when one thread is iterating through the
collection gotten from
#macro( drawStandardTextTranscript $meeting )
#foreach( $event in $meeting.getAllEvents() )
is another thread is modifying the collection, screwing up the iterator?
That's why I asked about what the getAllEvents() returns...
geir
On 11/5/01 11:06 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
> Geir,
>
> One of the events in question implements an interface and extends an
> abstract class. I will have to show you that interface and one abstract impl
> and two concrete implementations for it I'm interested in. Sorry for posting
> all this code, I can't think of another way to disclose the problem more
> consisely at the moment. Here is the Interface:
>
> -----8<-----
>
> package com.webhelp.emeeting.events;
>
> import java.util.Date;
>
> /**
> * IMeetingStoredEvent inteface.
> * This interface defines what it means to be an event that is persisted.
> */
> public interface IMeetingStoredEvent extends IMeetingEvent {
> static final long serialVersionUID = 9051789928189891274L;
>
> /**
> * Return the data in a format that is safe to be persisted. <br>
> * NOTE: This must be xml safe (ie. base 64)
> */
> public String getStoredData();
>
> /**
> * Build up the event's data using the stored data.
> */
> public void setStoredData(String storedData);
>
> /**
> * Return the date that the event occured
> */
> public Date getDate();
>
> /**
> * Set the event's date
> */
> public void setDate(Date date);
> }
>
> -----8<-----
>
> This is $chatEvent symbol:
>
> -----8<-----
>
> package com.webhelp.emeeting.events;
>
> import com.webhelp.emeeting.IMeeting;
> import java.util.Date;
>
> /**
> * ChatPublicEvent object.
> * This event is fire when a public (ie. everyone receives) text chat
> message occurs
> * in a meeting.
> */
> public class ChatPublicEvent extends ChatEvent {
> static final long serialVersionUID = 3612741022664978850L;
>
> /**
> * Constructor that only takes our source (Used by the database layer to
> recreate object)
> */
> public ChatPublicEvent(IMeeting source) {
> super(source);
> }
>
> /**
> * Constructor that takes the source and the chat messages
> */
> public ChatPublicEvent(IMeeting source, String chatMessage) {
> super(source, chatMessage);
> }
>
> }
> -----8<-----
>
> Which extends:
>
> -----8<-----
>
> package com.webhelp.emeeting.events;
>
> import com.webhelp.emeeting.IMeeting;
> import java.util.Date;
>
> /**
> * ChatEvent object.
> * This is the base class for all chat (ie. text message) events.
> * The source is a Meeting object. <br>
> * NOTE: This is a stored event.
> */
> public abstract class ChatEvent extends MeetingAppEvent implements
> IMeetingStoredEvent {
> static final long serialVersionUID = -6825658304993031299L;
>
> /**
> * This is our chat message.
> */
> private String chatMessage = null;
>
> /**
> * The event date
> */
> private Date date;
>
> /**
> * Constructor that only takes our source (Used by the database layer to
> recreate object)
> */
> public ChatEvent(IMeeting source) {
> super(source);
> // Note: The database layer sets the date when rebuilding
> }
>
> /**
> * Constructor that takes the source and the chat messages (Standard
> constructor)
> */
> public ChatEvent(IMeeting source, String chatMessage) {
> super(source);
>
> this.chatMessage = chatMessage;
> this.date = new Date(System.currentTimeMillis());
> }
>
> /**
> * Get our chat message
> */
> public String getChatMessage() {
> return this.chatMessage;
> }
>
> /**
> * Return the data in a format that is safe to be persisted. <br>
> * NOTE: This must be xml safe (ie. base 64)
> */
> public String getStoredData() {
> return this.chatMessage;
> }
>
> /**
> * Build up the event's data using the stored data.
> */
> public void setStoredData(String storedData) {
> this.chatMessage = storedData;
> }
>
> /**
> * set when this bad boy was made
> */
> public void setDate(Date date) {
> this.date = date;
> }
>
> /**
> * get when this was made
> */
> public Date getDate() {
> return this.date;
> }
>
> /**
> * Method declaration
> * @return
> */
> public String toString() {
> return super.toString() + ", msg=" + this.chatMessage;
> }
>
> }
>
> -----8<-----
>
>> On 11/5/01 10:25 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
>>
>>> Forgive me my inability to come up with a consise example of how to
>>> reproduce the error, if I had one I probably could have fixed it
>>> myself. I can't force this to reproduce itself except under our load
>>> testing environment at my company. I'm now working to consisely
>>> reproduce the problem in another contrived situation. I'm asking the
>>> community if anything I'm showing "rings a bell" to a problem.
>>>
>>> We use Velocity as a mail templating system. We recently discovered
>>> that in thousands of requests over a period of 5 minutes, the
>>> resulting merge() calls yield mysteriously incomplete emails. No
>>> exceptions are thrown, everything appears fine in the logs.
>>>
>>> Our typical template looks like this:
>>>
>>> -----8<-----
>>>
>>> #* $Id: Texten_msftrxbx.vtl,v 1.1 2001/11/05 15:06:40 hvanlaar Exp $
>>> *# #parse ( "functions.vtl" )
>>>
>>> $queue.getEmailSubject()
>>>
>>> Thank you for using Acme Center. Below is a copy of your chat session
>>> transcript for reference.
>>>
>>> Topic: $!meeting.getTopic()
>>>
>>> #drawStandardTextTranscript( $meeting )
>>>
>>> ==========
>>> $!repId:$meeting.getMeetingId()
>>>
>>> -----8<-----
>>>
>>> the parsed template, entitled "functions.vtl" looks like this:
>>>
>>> -----8<-----
>>>
>>> ...[other stuff]...
>>>
>>> #macro( drawStandardTextTranscript $meeting )
>>> #foreach( $event in $meeting.getAllEvents() )
>>> #set( $yapper = $meeting.getParticipation($event.getFromId()) )
>>> #if( $event.getClass().getName().equals($urlEvent) )
>>> $yapper.getName(): $event.getStoredData()
>>> #elseif( $event.getClass().getName().equals($chatEvent) )
>>> #if($repRole.equals($yapper.getRole()) )
>>> #set( $repId = $yapper.getParticipantId() )
>>> #end
>>> $yapper.getName(): $event.getStoredData()
>>> #end
>>> #end
>>> #end
>>>
>>> ...[other stuff]...
>>>
>>> -----8<-----
>>>
>>> The problem is the resulting output ocassionally (5-25% of the time)
>>> will not contain all $event.getStoredData() that it should. However,
>>> all the other stuff in the template will look fine: the footer and
>>> everything else. So, for some of the mails, there should be 15 lines
>>> of text, but we only see one or two. It's very strange and I cannot
>>> reproduce it outside of our load environment.
>>>
>>> Question is: is it possible some wierd threading behavior is ocurring?
>>> I'm not reusing a new VelocityContext for each call to merge() I'm
>>> making a new one each time. All other settings in Velocity are default
>>> except the template root, which I define.
>>>
>>> Thanks for any insights.
>>
>> Yeek :) We'll find it...
>>
>> 1) What version of Velocity?
>>
>> 2) what is the Class returned from '$meeting.getAllEvents()'?
>>
>> --
>> Geir Magnusson Jr.
>> geirm@optonline.net System and Software Consulting
>> "They that can give up essential liberty to obtain a little temporary
>> safety deserve neither liberty nor safety." - Benjamin Franklin
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org> For additional
>> commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
> --
> 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
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
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,
Posted by Nick Bauman <ni...@cortexity.com>.
Geir,
One of the events in question implements an interface and extends an
abstract class. I will have to show you that interface and one abstract impl
and two concrete implementations for it I'm interested in. Sorry for posting
all this code, I can't think of another way to disclose the problem more
consisely at the moment. Here is the Interface:
-----8<-----
package com.webhelp.emeeting.events;
import java.util.Date;
/**
* IMeetingStoredEvent inteface.
* This interface defines what it means to be an event that is persisted.
*/
public interface IMeetingStoredEvent extends IMeetingEvent {
static final long serialVersionUID = 9051789928189891274L;
/**
* Return the data in a format that is safe to be persisted. <br>
* NOTE: This must be xml safe (ie. base 64)
*/
public String getStoredData();
/**
* Build up the event's data using the stored data.
*/
public void setStoredData(String storedData);
/**
* Return the date that the event occured
*/
public Date getDate();
/**
* Set the event's date
*/
public void setDate(Date date);
}
-----8<-----
This is $chatEvent symbol:
-----8<-----
package com.webhelp.emeeting.events;
import com.webhelp.emeeting.IMeeting;
import java.util.Date;
/**
* ChatPublicEvent object.
* This event is fire when a public (ie. everyone receives) text chat
message occurs
* in a meeting.
*/
public class ChatPublicEvent extends ChatEvent {
static final long serialVersionUID = 3612741022664978850L;
/**
* Constructor that only takes our source (Used by the database layer to
recreate object)
*/
public ChatPublicEvent(IMeeting source) {
super(source);
}
/**
* Constructor that takes the source and the chat messages
*/
public ChatPublicEvent(IMeeting source, String chatMessage) {
super(source, chatMessage);
}
}
-----8<-----
Which extends:
-----8<-----
package com.webhelp.emeeting.events;
import com.webhelp.emeeting.IMeeting;
import java.util.Date;
/**
* ChatEvent object.
* This is the base class for all chat (ie. text message) events.
* The source is a Meeting object. <br>
* NOTE: This is a stored event.
*/
public abstract class ChatEvent extends MeetingAppEvent implements
IMeetingStoredEvent {
static final long serialVersionUID = -6825658304993031299L;
/**
* This is our chat message.
*/
private String chatMessage = null;
/**
* The event date
*/
private Date date;
/**
* Constructor that only takes our source (Used by the database layer to
recreate object)
*/
public ChatEvent(IMeeting source) {
super(source);
// Note: The database layer sets the date when rebuilding
}
/**
* Constructor that takes the source and the chat messages (Standard
constructor)
*/
public ChatEvent(IMeeting source, String chatMessage) {
super(source);
this.chatMessage = chatMessage;
this.date = new Date(System.currentTimeMillis());
}
/**
* Get our chat message
*/
public String getChatMessage() {
return this.chatMessage;
}
/**
* Return the data in a format that is safe to be persisted. <br>
* NOTE: This must be xml safe (ie. base 64)
*/
public String getStoredData() {
return this.chatMessage;
}
/**
* Build up the event's data using the stored data.
*/
public void setStoredData(String storedData) {
this.chatMessage = storedData;
}
/**
* set when this bad boy was made
*/
public void setDate(Date date) {
this.date = date;
}
/**
* get when this was made
*/
public Date getDate() {
return this.date;
}
/**
* Method declaration
* @return
*/
public String toString() {
return super.toString() + ", msg=" + this.chatMessage;
}
}
-----8<-----
> On 11/5/01 10:25 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
>
>> Forgive me my inability to come up with a consise example of how to
>> reproduce the error, if I had one I probably could have fixed it
>> myself. I can't force this to reproduce itself except under our load
>> testing environment at my company. I'm now working to consisely
>> reproduce the problem in another contrived situation. I'm asking the
>> community if anything I'm showing "rings a bell" to a problem.
>>
>> We use Velocity as a mail templating system. We recently discovered
>> that in thousands of requests over a period of 5 minutes, the
>> resulting merge() calls yield mysteriously incomplete emails. No
>> exceptions are thrown, everything appears fine in the logs.
>>
>> Our typical template looks like this:
>>
>> -----8<-----
>>
>> #* $Id: Texten_msftrxbx.vtl,v 1.1 2001/11/05 15:06:40 hvanlaar Exp $
>> *# #parse ( "functions.vtl" )
>>
>> $queue.getEmailSubject()
>>
>> Thank you for using Acme Center. Below is a copy of your chat session
>> transcript for reference.
>>
>> Topic: $!meeting.getTopic()
>>
>> #drawStandardTextTranscript( $meeting )
>>
>> ==========
>> $!repId:$meeting.getMeetingId()
>>
>> -----8<-----
>>
>> the parsed template, entitled "functions.vtl" looks like this:
>>
>> -----8<-----
>>
>> ...[other stuff]...
>>
>> #macro( drawStandardTextTranscript $meeting )
>> #foreach( $event in $meeting.getAllEvents() )
>> #set( $yapper = $meeting.getParticipation($event.getFromId()) )
>> #if( $event.getClass().getName().equals($urlEvent) )
>> $yapper.getName(): $event.getStoredData()
>> #elseif( $event.getClass().getName().equals($chatEvent) )
>> #if($repRole.equals($yapper.getRole()) )
>> #set( $repId = $yapper.getParticipantId() )
>> #end
>> $yapper.getName(): $event.getStoredData()
>> #end
>> #end
>> #end
>>
>> ...[other stuff]...
>>
>> -----8<-----
>>
>> The problem is the resulting output ocassionally (5-25% of the time)
>> will not contain all $event.getStoredData() that it should. However,
>> all the other stuff in the template will look fine: the footer and
>> everything else. So, for some of the mails, there should be 15 lines
>> of text, but we only see one or two. It's very strange and I cannot
>> reproduce it outside of our load environment.
>>
>> Question is: is it possible some wierd threading behavior is ocurring?
>> I'm not reusing a new VelocityContext for each call to merge() I'm
>> making a new one each time. All other settings in Velocity are default
>> except the template root, which I define.
>>
>> Thanks for any insights.
>
> Yeek :) We'll find it...
>
> 1) What version of Velocity?
>
> 2) what is the Class returned from '$meeting.getAllEvents()'?
>
> --
> Geir Magnusson Jr.
> geirm@optonline.net System and Software Consulting
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety." - Benjamin Franklin
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>
--
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,
both 1.1 and 1.2-dev
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 11/5/01 10:25 AM, "Nick Bauman" <ni...@cortexity.com> wrote:
> Forgive me my inability to come up with a consise example of how to
> reproduce the error, if I had one I probably could have fixed it myself. I
> can't force this to reproduce itself except under our load testing
> environment at my company. I'm now working to consisely reproduce the
> problem in another contrived situation. I'm asking the community if anything
> I'm showing "rings a bell" to a problem.
>
> We use Velocity as a mail templating system. We recently discovered that in
> thousands of requests over a period of 5 minutes, the resulting merge()
> calls yield mysteriously incomplete emails. No exceptions are thrown,
> everything appears fine in the logs.
>
> Our typical template looks like this:
>
> -----8<-----
>
> #* $Id: Texten_msftrxbx.vtl,v 1.1 2001/11/05 15:06:40 hvanlaar Exp $ *#
> #parse ( "functions.vtl" )
>
> $queue.getEmailSubject()
>
> Thank you for using Acme Center. Below is a copy of your chat session
> transcript for reference.
>
> Topic: $!meeting.getTopic()
>
> #drawStandardTextTranscript( $meeting )
>
> ==========
> $!repId:$meeting.getMeetingId()
>
> -----8<-----
>
> the parsed template, entitled "functions.vtl" looks like this:
>
> -----8<-----
>
> ...[other stuff]...
>
> #macro( drawStandardTextTranscript $meeting )
> #foreach( $event in $meeting.getAllEvents() )
> #set( $yapper = $meeting.getParticipation($event.getFromId()) )
> #if( $event.getClass().getName().equals($urlEvent) )
> $yapper.getName(): $event.getStoredData()
> #elseif( $event.getClass().getName().equals($chatEvent) )
> #if($repRole.equals($yapper.getRole()) )
> #set( $repId = $yapper.getParticipantId() )
> #end
> $yapper.getName(): $event.getStoredData()
> #end
> #end
> #end
>
> ...[other stuff]...
>
> -----8<-----
>
> The problem is the resulting output ocassionally (5-25% of the time) will
> not contain all $event.getStoredData() that it should. However, all the
> other stuff in the template will look fine: the footer and everything else.
> So, for some of the mails, there should be 15 lines of text, but we only see
> one or two. It's very strange and I cannot reproduce it outside of our load
> environment.
>
> Question is: is it possible some wierd threading behavior is ocurring? I'm
> not reusing a new VelocityContext for each call to merge() I'm making a new
> one each time. All other settings in Velocity are default except the
> template root, which I define.
>
> Thanks for any insights.
Yeek :) We'll find it...
1) What version of Velocity?
2) what is the Class returned from '$meeting.getAllEvents()'?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>