tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Davidson" <>
Subject RE: Multiple HTTPConnections in parallel from EJB
Date Sun, 21 Feb 2010 16:19:29 GMT
Hi Karsten.

You would be surprised.  A JMS Queue itself has minimal overhead (they
have to have low overhead if they are going to have high throughput, and
most do have high throughput).  And if required, there is nothing saying
the MDBs would have to be on the same machine as the Queue.  If the
messages are small (generally below 64K), remote has minimal performance
hit for most Message Queue techs that I am familiar with.

Caution on the MBeans -- they are singletons, so you can't store state
of a process in one, only state (and config items!) as properties in


-----Original Message-----
From: Karsten Ohme [] 
Sent: Sunday, February 21, 2010 3:33 AM
Subject: Re: Multiple HTTPConnections in parallel from EJB

Am 19.02.2010 22:28, schrieb Stephen Davidson:

But I guess the performance is not optimal here? I mean, two JMS queues
in the background for a single HTTP call is a lot.
I think I try the Managed Bean approach.

> Hi Karsten.
> Why I said two Queues.  Transmit everything on one (or one set,
> depending), then listen on the response queue.  More than just an MDB
> can listen on a Queue, btw, including Stateless EJBs, or even POJOs.
> MDBs normally "auto-register" as a listener on a Queue (depending on
> AppServer).  Everything else has to programmatically connect (to a
> sometimes pre-existing Queue).
> So, as the requests are processed (or timeout!), the MDBs post to the
> Response Queue, where the sender is listening.  Note that you might
> to dynamically create a response queue for each set of requests you
> handling, and transmit what that queue is as part of the original
> message.  Once the sender has received responses from all the MDBs, it
> can continue processing.  Going this route, you don't even need
> everything on the same machine, although doing so will make
> configuration simpler.
> Regards,
> Steve
> -----Original Message-----
> From: Karsten Ohme [] 
> Sent: Friday, February 19, 2010 3:17 PM
> To:
> Subject: Re: Multiple HTTPConnections in parallel from EJB
> Thanks for the quick reply.
> the second possibility seems to be a problem: I have to wait until all
> results are collected. This seems to be impossible with MDB. Or how
> I wait in an EJB  until all MDBs have collected all results for a
> specific request?
> Karsten
> Am 19.02.2010 21:57, schrieb Stephen Davidson:
>> <quickie answer>
>> Two technologies that come to mind for this;
>> MBeans aka JMX Beans (multi-threading IS allowed here)
>> MDB with channels/subqueues - one queue for transmitting requests,
>> another queue for picking up responses.  Then X number of MDBs
> listening
>> for requests, with each doing its own HTTP Processing.
>> </quickie answer>
>> Regards,
>> Steve
>> -----Original Message-----
>> From: Karsten Ohme [] 
>> Sent: Friday, February 19, 2010 2:52 PM
>> To:
>> Subject: Multiple HTTPConnections in parallel from EJB
>> Hi Java Gurus,
>> We have the following problem:
>> We are using the HTTPClient library and must open multiple
>> simultaneously. i.e. we have to make several calls in parallel,
>> otherwise the performance is very bad. If we have 50 requests per
>> and are doing these 50 requests in order we have to wait 50 times the
>> time of one request. For multiple user this is not an option.
>> So, the question is how can 50 parallel connection be opened in EJB?
>> Threads are not allowed, so how can we accomplish this?
>> It should be a service like this:
>> - Send x methods in parallel
>> - Collects the results
>> Thanks,
>> Karsten

Karsten Ohme
T-Systems Multimedia Solutions GmbH
Portal Technologies, Applications & Appliances
Hausanschrift: Riesaer Strasse 5, 01129 Dresden
Postanschrift: Postfach 10 02 24, 01072 Dresden
Telefon: +49 351 28 20 - 2123
Fax: +49 171 351 28 20 - 5116

View raw message