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