Hitachi Vantara Pentaho Community Forums
Results 1 to 4 of 4

Thread: [Mondrian] RolapResultShepherd

  1. #1
    Julian Hyde Guest

    Default [Mondrian] RolapResultShepherd

    Luc,

    Instead of RolapResultShepherd, you could have used a timer to check on the status of each execution -- thoughts on that? RolapResultShepherd is a "server process" (by which I mean an ongoing thing that consumes resources and has to be shut down and generally makes mondrian heavier weight) and I question whether we need it. But I kind of like RolapResultShepherd -- don't change it.

    Quite a few errors now come out wrapped in an extra java.util.concurrent.ExecutionException (if they come through shepherdExecution). It doesn't give any extra information to the end user. Can you strip it away please?

    Julian
    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  2. #2
    Luc Boudreau Guest

    Default Re: [Mondrian] RolapResultShepherd

    Hi Julian,

    I used a dedicated daemon thread so that one and only one thread would run
    this process, optimized the code so that it does as little as possible, then
    made sure that it would enter a sleeping state between the runs. Having a
    timer thread amounts to the roughly the same (IIRC JVMs implement it as a
    separate thread as well), but with less control over what the thread
    actually does, when it sleeps and what have you. I can convert it to use
    Timer, but I don't see how this would use less resources.

    As for the exception striping, I was skeptical at first about doing this, as
    I would end up wrapping checked exceptions in a MondrianException, so back
    to square one. I'll give it a try and see if I can do it in a more elegant
    way.

    Cheers!

    Luc


    On Sun, Aug 14, 2011 at 1:14 AM, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > Luc,
    >
    > Instead of RolapResultShepherd, you could have used a timer to check on the
    > status of each execution -- thoughts on that? RolapResultShepherd is a
    > "server process" (by which I mean an ongoing thing that consumes resources
    > and has to be shut down and generally makes mondrian heavier weight) and I
    > question whether we need it. But I kind of like RolapResultShepherd -- don't
    > change it.
    >
    > Quite a few errors now come out wrapped in an extra
    > java.util.concurrent.ExecutionException (if they come through
    > shepherdExecution). It doesn't give any extra information to the end user.
    > Can you strip it away please?
    >
    > Julian


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  3. #3
    Joe Barnett Guest

    Default Re: [Mondrian] RolapResultShepherd

    Hi Luc,

    One comment:

    On Mon, Aug 15, 2011 at 9:03 AM, Luc Boudreau <lucboudreau (AT) gmail (DOT) com> wrote:
    > Hi Julian,
    >
    > I used a dedicated daemon thread so that one and only one thread would run
    > this process...


    It looks like you're rather using a dedicated thread pool, not a
    single thread? Executors.newCachedThreadPool() should be creating new
    threads as necessary, I believe. Which should be what we want anyway,
    so that concurrent query requests are not serialized behind one
    another. Haven't gotten around to testing this yet though, have you?

    Thanks,
    -Joe
    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

  4. #4
    Luc Boudreau Guest

    Default Re: [Mondrian] RolapResultShepherd

    To be exact, yes I do use the same thread pool for both the shepherd thread
    and the execution threads, but the class initialization routine launches a
    single static FutureTask which performs the shepherding, and this task is
    not killed until the JVM shuts down. The requests coming in later on create
    new threads from that same pool and are re-used as necessary. As before,
    each request can be processed concurrently.

    Luc

    On Mon, Aug 15, 2011 at 12:21 PM, Joe Barnett <thejoe (AT) gmail (DOT) com> wrote:

    > Hi Luc,
    >
    > One comment:
    >
    > On Mon, Aug 15, 2011 at 9:03 AM, Luc Boudreau <lucboudreau (AT) gmail (DOT) com>
    > wrote:
    > > Hi Julian,
    > >
    > > I used a dedicated daemon thread so that one and only one thread would

    > run
    > > this process...

    >
    > It looks like you're rather using a dedicated thread pool, not a
    > single thread? Executors.newCachedThreadPool() should be creating new
    > threads as necessary, I believe. Which should be what we want anyway,
    > so that concurrent query requests are not serialized behind one
    > another. Haven't gotten around to testing this yet though, have you?
    >
    > Thanks,
    > -Joe
    > _______________________________________________
    > Mondrian mailing list
    > Mondrian (AT) pentaho (DOT) org
    > http://lists.pentaho.org/mailman/listinfo/mondrian
    >


    _______________________________________________
    Mondrian mailing list
    Mondrian (AT) pentaho (DOT) org
    http://lists.pentaho.org/mailman/listinfo/mondrian

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.