[Mondrian] [Olap4j-devel] olap4j-xmlaserver: Initial refactoring of Mondrian's XMLA server into its own project

Wed Oct 2 05:00:41 EDT 2013

Sounds like the connections are pooled but never getting closed/reused. If
you find a way to better manage their lifecycle, this problem will go away.

Luc

On Wed, Oct 2, 2013 at 3:18 AM, Benedikt Kämpgen
<benedikt.kaempgen at kit.edu>wrote:

> Hi Michele,
>
> Thanks a lot for your quick answer.
>
> I guess, eventually, xmlaserver needs a sustainable solution, here. For
> now, it would be very nice, if you give me the code so I can implement
> that workaround in my system, also.
>
> Best,
>
> Benedikt
>
> On 10/01/2013 11:39 PM, Michele Rossi wrote:
> > Hi guys,
> > yeah you are running into the problem I described back in June, the code
> as it is now is broken.
> > Unfortunately at the moment I don't have any time to spare for this but
> my solution was basically a map of connection wrappers that held the
> connection and the time stamp of its last use. Then a 'reaper' thread
> cleaning idle connections.
> >
> > No commons-pool as I could never get it to work.
> >
> > hope this helps. I still have the code somewhere, give me a shout if you
> want it.
> >
> > Michele
> >
> > Sent from my iPhone
> >
> >> On 1 Oct 2013, at 22:27, Benedikt Kämpgen <benedikt.kaempgen at kit.edu>
> wrote:
> >>
> >> Hello,
> >>
> >> In our system using xmlaserver [2] with an olap4j driver we now run
> into connection pooling problems.
> >>
> >> After some (sometimes more, sometimes fewer) xmla requests, any new
> request would hang in "Daemon Thread [http-8080-2]" at:
> >>
> >> --------------------------
> >> Object.wait (long) line: not available [native method]
> >> GenericObjectPool$Latch(Object).wait()
> >> GenericObjectPool.borrowObject()
> >> ...
> >> BasicDataSource.getConnection()
> >> Olap4jPoolingConnectionFactory.getConnection()
> >> ...
> >> --------------------------
> >>
> >> We use un-authenticated connections.
> >>
> >> It may be related to the problem Michele mentioned in the last mail.
> Another possibility would be that our olap4j driver [1] does not fulfill
> all requirements xmlaserver puts on olap4j drivers.
> >>
> >> Any ideas how we can solve this problem are greaty appreciated.
> >>
> >> Best,
> >>
> >> Benedikt
> >>
> >> [1] <http://olap4ld.googlecode.com/>
> >> [2] <https://github.com/olap4j/olap4j-xmlaserver>
> >>
> >>> On 06/10/2013 05:01 PM, Michele Rossi wrote:
> >>> hi Luc,
> >>> sure, a couple of years ago I did part of the work to have the XMLA
> >>> Servlet use any Olap4j driver (attached an example web.xml) and I also
> >>> did some work with Julian on the connection pooling.
> >>>
> >>> Julian decided that we should use commons-pool to handle the pool of
> >>> OlapConnection objects.
> >>> I initially opted for a much simpler solution which I committed but
> >>> later Julian decided to change it back to the commons-pool stuff.
> >>>
> >>> I found that when the size of the pool reaches the maximum number of
> >>> connections configured the thread that attempts to obtain the
> connection
> >>> freezes waiting to obtain a new connection from the pool.
> >>>
> >>> I also found that the connection pool didn't really re-use any existing
> >>> connections preferring instead to create new ones for each requests
> >>> (until the situation described above occured).
> >>>
> >>> At the time it didn't seem like there was a huge amount of interest on
> >>> the XMLA servlet and because I never got any other feedback about it I
> >>> didn't attempt to have my changes committed to trunk again.
> >>>
> >>> I am happy to share that code with the community again if you want.
> >>>
> >>>
> >>> That said, I have not seen the mondrian / xmlaservlet code for a while,
> >>> maybe someone has changed things again in the meantime.
> >>>
> >>>
> >>> Hope this helps.
> >>> Michele
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 10 June 2013 16:11, Luc Boudreau <lucboudreau at gmail.com
> >>> <mailto:lucboudreau at gmail.com>> wrote:
> >>>
> >>>
> >>>     On Thu, Jun 6, 2013 at 5:45 PM, Michele Rossi
> >>>     <m.rossi at iontrading.com <mailto:m.rossi at iontrading.com>> wrote:
> >>>
> >>>         the connection pooling code that is in there now (based on
> >>>         commons-pool) is totally broken, your XMLA client (Excel 2007?)
> >>>         could get stuck forever waiting to obtain a new OlapConnection
> >>>         connection object
> >>>
> >>>
> >>>
> >>>     Michele,
> >>>
> >>>     Can you clarify this statement? That is worrying me a little.
> >>>
> >>>     Luc
> >>>
> >>>
> >>>     _______________________________________________
> >>>     Mondrian mailing list
> >>>     Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
> >>>     http://lists.pentaho.org/mailman/listinfo/mondrian
> >>
> >> --
> >> AIFB, Karlsruhe Institute of Technology (KIT)
> >> Phone: +49 (721) 608 48941
> >> Email: benedikt.kaempgen at kit.edu
> >> Web: http://www.aifb.kit.edu/web/Hauptseite/en
> >>
> >>
>
> --
> AIFB, Karlsruhe Institute of Technology (KIT)
> Phone: +49 (721) 608 48941
> Email: benedikt.kaempgen at kit.edu
> Web: http://www.aifb.kit.edu/web/Hauptseite/en
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> olap4j-devel mailing list
> olap4j-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20131002/3a025f32/attachment.html 