Mailing-List: contact users-help@openejb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openejb.apache.org
Received-SPF: pass (nike.apache.org: domain of david.blevins@visi.com
 designates 208.42.176.212 as permitted sender)
Message-Id: <008133DA-386C-42F2-80B1-AFF537FD8BF0@visi.com>
From: David Blevins <david.blevins@visi.com>
To: users@openejb.apache.org
In-Reply-To: <1f3854d50911070558y59b18a44t1caf95a4b53b0a63@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Remote EJB re-establish
Date: Tue, 10 Nov 2009 13:57:22 -0800
References: <1f3854d50911070558y59b18a44t1caf95a4b53b0a63@mail.gmail.com>


On Nov 7, 2009, at 5:58 AM, Quintin Beukes wrote:

> Hey,
>
> I might have asked this question before - though I can't find the  
> mail, so
> if I did, I deleted it.
>
> Either way, I was pretty amazed yesterday. So much I'm not sure I  
> imagined
> it.
>
> I had an open application that I've done some EJB invocations in.  
> Then I
> redeployed my EJBs. I went to the app and was able to continue without
> problems. With GF I had to restart the app. Does OpenEJB handle this  
> as I
> think it did?

Not all connection hangups are equal, but we do have some code in  
there to deal with this where we are able to detect it.

> Secondly. This I know i've asked, though I'd just like to confirm it  
> for
> G2.2 with OpenEJB 3.1.2 and expand on it.
> a) Does OpenEJB, when you create a remote context keep an open  
> connection at
> all times, or does it get a session key and have a detached session  
> context?

We keep a small pool of open connections (5 by default) for as long as  
the server will let us (5 minutes by default).

> b) If in either of these cases a connection fails, will it  
> transparently
> attempt to recover from this?

Depends on the hangup.  TCP is notoriously resilient and will not  
report a connection as closed for several minutes sometimes even when  
it is cleanly closed on the server side.  If a network goes down,  
either side will try really hard not to fail and will happily accept  
any bytes you wish to write -- only when reading will you get a  
exception.

So on the client side we will automatically retry if we are unable to  
write the request.  If we are able to write the request but reading  
fails, than by default we will *not* retry as we have to assume the  
server received the request -- we do not want to run the risk of  
potentially executing important transactional work twice.

We do have some undocumented dip-switches and flags that will enable  
connection "testing" ping/pong logic between the client and server as  
well as the ability to retry even when a full request write does occur  
but response read fails.  I can give you some pointers if you want to  
dig around and help document them :)

-David