OK there is a lot in what you said.
I hold my head in shame as obviously we are using Velocity in a way we
shouldn't. I am just trying to pick up the pieces here.
Regarding the merge issue the answer is we are calling this for each
piece of content and so forth. Should I do a parse here? Would it be
faster/better?
public String mergeTemplate(String templatePath) throws
ResourceNotFoundException, ParseErrorException, Exception{
VelocityEngine ve = VelocityUtil.getEngine();
Template template = null;
StringWriter sw = new StringWriter();
template = ve.getTemplate(templatePath);
template.merge(ctx, sw);
return sw.toString();
}
The code around the parser is
static private final class LookaheadSuccess extends java.lang.Error { }
final private LookaheadSuccess jj_ls = new LookaheadSuccess();
private boolean jj_scan_token(int kind) {
if (jj_scanpos == jj_lastpos) {
jj_la--;
if (jj_scanpos.next == null) {
jj_lastpos = jj_scanpos = jj_scanpos.next = token_source.getNextToken();
} else {
jj_lastpos = jj_scanpos = jj_scanpos.next;
}
} else {
jj_scanpos = jj_scanpos.next;
}
if (jj_rescan) {
int i = 0; Token tok = token;
while (tok != null && tok != jj_scanpos) { i++; tok = tok.next; }
if (tok != null) jj_add_error_token(kind, i);
}
if (jj_scanpos.kind != kind) return true;
if (jj_la == 0 && jj_scanpos == jj_lastpos) throw jj_ls;
return false;
}
Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422
On Mon, Sep 13, 2010 at 1:10 PM, Nathan Bubna <[email protected]> wrote:
> On Mon, Sep 13, 2010 at 9:40 AM, Jason Tesser <[email protected]> wrote:
>> Let me try and give you a better picture of what is happening.
>>
>> We have a Page (which is a Velocity Template) not much on it but a
>> bunch of sets.
>> The page parses the template (also a Velocity Template) this has HTML
>> and parses 0 to many containers.
>> The container (also a Velocity Template) loops over and parses Content.
>> Each content is a Velocity Template.
>>
>> In my example I have a page with one container and 500 pieces of content in
>> it.
>
> translation: we decided to use Velocity as a scripting language,
> despite decades of Velocity developers repeated declarations that
> Velocity is a template engine and is not and will never be designed
> with scripting in mind.
>
> and what's with $velutil.mergeTemplate('blahblah')? does #parse() offend?
>
> ok, so i try to be a pragmatist first and idealist second, but i just
> want you to be aware that you have invited this headache upon
> yourself. if this approach works best for you, i won't harp on it, as
> long as i know you know this is anything but a best practice. of
> course, my scolding does nothing to aid you with your problem. so,
> i'll shut up now and go back to pragmatism. :)
>
>> If I hit in the browser it all works but is a bit slow first time.
>> Then it is in cache and is not too bad.
>>
>> It should also be mentioned that the parses are actually Merges
>> template.merge()
>
> that doesn't make sense to me; parsing happens in template.process(),
> not template.merge(...) two different processes. unless you mean
> engine.mergeTemplate(...) which will parse uncached templates and then
> merge them.
>
>> If I put load using siege or jmeter it totally breaks down as I
>> described. The debugger isn't tellme me a whole lot.
>> I will attach a thread dump and some of the velocity files.
>
> yeah, that doesn't tell me much either. i still don't know what the
> pertinent Parser.java code is (line numbers vary there and didn't
> reveal anything obvious to me), and i suspect it probably won't help
> anyway, as this is more likely to be some thread lock or memory issue
> that is beyond my ability to remotely (and perhaps even locally)
> debug.
>
>> I know I am in cache and h2 but notice all the
>> http://pastebin.com/pg42QGue
>>
>> Now the velocity being hit
>> This is the page
>> http://pastebin.com/AMm8wxyf
>>
>> The template
>> http://pastebin.com/BG8CA0HF
>>
>> The container
>> http://pastebin.com/3g4UL6KT
>>
>> and then 500 contents that look like this
>> http://pastebin.com/feN26eEK
>>
>> what happens is each content gets merged.
>>
>> Thanks,
>> Jason Tesser
>> dotCMS Lead Development Manager
>> 1-305-858-1422
>>
>>
>>
>> On Mon, Sep 13, 2010 at 12:11 PM, Nathan Bubna <[email protected]> wrote:
>>> On Mon, Sep 13, 2010 at 8:47 AM, Jason Tesser <[email protected]> wrote:
>>>> Question for you
>>>>
>>>> My velocityengine is a singletons right now.
>>>>
>>>> Could having multiple VelocityEngines help? Could I be up against some
>>>> limit here under load?
>>>
>>> Without knowing more about what is going on, it's really hard to say.
>>> It would help to know more. I still struggle to imagine what is
>>> causing things to hang at that line. You say you were using 1.6.3?
>>> Because line 3391 in Parser.java doesn't look like that in 1.6.3,
>>> 1.6.4 or the trunk. I'd like to see the surrounding code, to see if i
>>> can understand better what is happening. Does your debugger tell you
>>> anything else? Like how many Parser objects exist at the time? Are
>>> there any other choke points? Are you seeing "Created <X> parsers."
>>> debug output in your logs?
>>>
>>> And you could always just try using multiple engines and see if it
>>> helps. Depending on how difficult that refactor is, sometimes guess
>>> and check really is the fastest way to a solution. :)
>>>
>>>> Thanks,
>>>> Jason Tesser
>>>> dotCMS Lead Development Manager
>>>> 1-305-858-1422
>>>>
>>>>
>>>>
>>>> On Mon, Sep 13, 2010 at 11:40 AM, Nathan Bubna <[email protected]> wrote:
>>>>> it kinda sounds like the stuck threads are waiting for a lock to be
>>>>> released.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
