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@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@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@gmail.com
>>> <mailto:lucboudreau@gmail.com>> wrote:
>>>
>>>
>>>     On Thu, Jun 6, 2013 at 5:45 PM, Michele Rossi
>>>     <m.rossi@iontrading.com <mailto:m.rossi@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@pentaho.org <mailto:Mondrian@pentaho.org>
>>>     http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>> --
>> AIFB, Karlsruhe Institute of Technology (KIT)
>> Phone: +49 (721) 608 48941
>> Email: benedikt.kaempgen@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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/olap4j-devel