[Topaz-dev] Mulgara Performance Woes

[Andrae Muys]

On 03/03/2008, at 9:47 PM, Life is hard, and then you die wrote:

>
> [warning: the rest here is _not_ applicable to our current mulgara
> usage which is via soap, but to the future usage which is via RMI]
>
> On Sat, Mar 01, 2008 at 09:51:46PM +1000, Andrae Muys wrote:
>>
>> On 01/03/2008, at 3:45 AM, Russell Uman wrote:
>>
>>>
>>>> We need some idea of A) how long transactions are being kept
>>>> open,
>>>
>>> because certain things take a long time to serve (search, feeds,
>>> etc.).
>>> because once the pub-app times out its connection to mulgara,  
>>> mulgara
>>> keeps the transaction open for a long time, hopefully waiting.
>>
>> There's been a pending feature request to provide some sort of
>> keepalive on session connections for quite a while now, maybe this is
>> the impetus needed to push it to the front of the queue.
>
> Hmm, I thought RMI controlled connections? Is there a way to manage
> them? Or are you talking about having mulgara issue some sort no-op on
> the client side periodically in hopes of keeping the underlying
> rmi/tcp connection open? Do you know, does Sun's RMI implementation
> multiplex different requests over a single tcp connection, or does it
> use a separate connection for each request in progress?

Not so much a question of keeping the connection open, as detecting  
when the other-side goes away. I haven't taken the time to  
investigate exactly what is happening on the wire - although 10- 
minutes and a copy of ethereal will resolve that if we need to :).

>> On the other hand, if we used a two-level lock for the write-lock we
>> could support a preemptive close operation on session - allowing you
>> to clear the queue as app's timeout.
>
> Not sure if that will buy much: if a session is waiting on the
> write-lock can't you already go and close() it from another thread?
> (Ok, I believe it'll still acquire the lock but then it'll quickly
> notice the session has been closed and release it again - at least
> that was my understanding).

Yeah, you're right - there's no reentrancy check on session.close(),  
so while the resulting abort isn't as clean as a two-level lock, the  
outcome is the same.

Andrae

P.S. As I'm reading/writing email again this means I am finally in  
SF :)  Hopefully I'll get a chance to meet many of you while I'm up.

-- 
Andrae Muys
andrae at netymon.com
Senior RDF/SemanticWeb Consultant
Netymon Pty Ltd