At some point I thought I remember being told or finding out that the
merge was faster then a parse or an evaluate.
Also I think there were issues with the context when we parsed
everything. We do alot with the context.
Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422
On Mon, Sep 13, 2010 at 1:48 PM, Nathan Bubna <nbu...@gmail.com> wrote:
> On Mon, Sep 13, 2010 at 10:31 AM, Jason Tesser <jasontes...@gmail.com> wrote:
>> 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.
>
> aw, now i feel bad for scolding... :(
>
>> 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?
>
> it might be a little faster (no new StringWriter, no $velutil
> introspection), but i would guess it to not be much faster. main
> benefit is simplicity. if you don't have a really good reason, it
> usually best to avoid reinventing the wheel.
>
>> 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;
>> }
>
> i went ahead and just generally scanned the parsing code and it looks
> unlikely that there is any lock contention issue. so, i'm out of my
> depth. Christoph's suggestion seems plausible, but i haven't ever had
> to deal with anything like that. if his advice doesn't work out, then
> i would try taking the question to the JavaCC mailing list. Someone
> there might know better what could be causing this.
>
>> Thanks,
>> Jason Tesser
>> dotCMS Lead Development Manager
>> 1-305-858-1422
>>
>>
>>
>> On Mon, Sep 13, 2010 at 1:10 PM, Nathan Bubna <nbu...@gmail.com> wrote:
>>> On Mon, Sep 13, 2010 at 9:40 AM, Jason Tesser <jasontes...@gmail.com> 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 <nbu...@gmail.com> wrote:
>>>>> On Mon, Sep 13, 2010 at 8:47 AM, Jason Tesser <jasontes...@gmail.com>
>>>>> 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 <nbu...@gmail.com> wrote:
>>>>>>> it kinda sounds like the stuck threads are waiting for a lock to be
>>>>>>> released.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>>>>>> For additional commands, e-mail: user-h...@velocity.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>>>>> For additional commands, e-mail: user-h...@velocity.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>>>> For additional commands, e-mail: user-h...@velocity.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>>> For additional commands, e-mail: user-h...@velocity.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: user-h...@velocity.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
> For additional commands, e-mail: user-h...@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
