On Mon, Sep 13, 2010 at 10:51 AM, Jason Tesser <jasontes...@gmail.com> wrote:
> At some point I thought I remember being told or finding out that the
> merge was faster then a parse or an evaluate.
What you are doing is essentially a #parse call, but with an
additional Writer involved. and #parse (or your code) are really only
superior to evaluate when template caching is on, to avoid reparsing
at every call. There is parsing, and there is merging. You can never
escape the merging, but you can avoid reparsing so long as you run
through resource loaders that support caching and have it turned on.
> Also I think there were issues with the context when we parsed
> everything. We do alot with the context.
sounds plausible. :)
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
