Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
Message-ID: <41122F86.2040304@u.washington.edu>
Date: Thu, 05 Aug 2004 09:00:54 -0400
From: Michael Becke <becke@u.washington.edu>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: Invoke a httpclient in a EJB
References: <20040805124838.630.qmail@web50204.mail.yahoo.com>
In-Reply-To: <20040805124838.630.qmail@web50204.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Karthi,

 From the wording it sounds like you are not supposed to run a server 
from an EJB.  HttpClient creates sockets but it does not listen to or 
accept connections, it's a client only.  As someone already mentioned it 
would be pretty useless if you couldn't make network connections from an 
EJB as that would eliminate JDBC as well.

It sounds like the real issue is going to be thread creation and 
connection reuse.  To avoid creating threads you should use neither the 
MultiThreadedHttpConnectionManager nor connection timeouts.  Both of 
these will create threads.  You will also need to ensure that all 
HttpConnections are closed when the EJB exists.  I would suggest 
creating a simple HttpConnectionManager (very similar to 
SimpleHttpConnectionManager) that you can force close the connection with.

Mike

Karthikeyani K wrote:

> Thanks everyone.
> 
> The EJB restrictions specified at
> http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html state
> that Enterprise beans should not listen on, accept connections on, or
> mutlicast from a network socket. Why can an enterprise bean not
> listen to or accept connections on a socket? Because if an enterprise
> bean is listening on a socket, it can't be passivated -- it must
> always be available. Enterprise beans can be network socket clients,
> and so they can use other network resources (including other
> enterprise bean servers) to do their jobs. Just as with a database
> connection, don't hang on to open client sockets across method calls;
> instead, open them, communicate through the socket, and close it
> before returning from the method.
> 
> So does it mean that we cannot use a HttpClient to invoke a
> postmethod from within a EJB, as httpclient creates sockets.  Please
> clarify. Is there any other alternate way.
> 
> Thanks,
> 
> Karthi
> 
> 
> Gareth Davis <gareth@logicalpractice.com> wrote: EJB + threads +
> httpclient... yes does break the letter of the spec's, but yep it
> works and it works just fine.
> 
> Who ever wrote the spec that said you couldn't open a socket in an
> EJB really wasn't living in the real world.
> 
> The only thing to watch is that MultiThreadedConnectionManager does 
> start it's own thread for managing the pool, this does work in an EJB
>  but it won't be shutdown correctly when the application is stopped,
> you may find that you create a thread leak.
> 
> Having said this I've only tried this in WebSphere 4 and 5. Version 4
>  it wasn't a big deal as the process for the appserver got restarted
>  when re-installing the app, but in websphere 5 it caused a leak.
> 
> Gareth Davis Logical Practice Systems Limited
> 
> gareth@logicalpractice.com On 4 Aug 2004, at 16:20, Karthikeyani K
> wrote:
> 
> 
>> Hi, We have all requests posted to a servlet which delegates the 
>> request to a Stateless Session Bean. Does creatring and invoking a
>>  Httpclient postmethod in a helper class invoked by the Stateless 
>> Session Bean violate any of the EJB specifications. (EJB spec says
>>  sockets are not to be created in EJB code etc. ). Please suggest.
>> 
>> 
>> Thanks, Karthi
>> 
>> __________________________________________________ Do You Yahoo!? 
>> Tired of spam? Yahoo! Mail has the best spam protection around 
>> http://mail.yahoo.com
> 
> 
> 
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional
> commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 
> 
>  --------------------------------- Do you Yahoo!? New and Improved
> Yahoo! Mail - Send 10MB messages!

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org