Hi All,

He Binildas can you please explain one doubt of mine.

That pub / sub technology in JMS is based on push model.
As suppose Im using MDB then I'll associate one Port with the
topicConnectionFactory/topicConnection and then associate MDB with the Port
created. Then whenever any message is published then that partcular MDB
would be called.

And in the case of Point 2 Point (Queue) the modal is pull.
In this case the listener will not be called implicitly. In this case we
have to create the Listener as not in the former case of MDB.
Is my concepts are correct.

Please explian.
Many Thanks.

Manish Malhotr

-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected).
Sent: Monday, July 19, 2004 2:22 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: [SPAM] - Re: Regarding restricting number of instant for
MDB - Found word(s) list error in the Text body.


"Is it a correct approach?" - This is one (and preferred) way of doing it.

"Is my understanding correct?" - Correct, provided the configuration for
max-beans-in-free-pool has not exceeded.

"then the 6th message needs to wait " - For this we dont need to do anything
explicitely, since JMS Message Provider will have mechanism to store the
Message. Whether this message stored is persistant or not - depends upon
again on App Server configuration. Fine - that is the storage part. Now in
the consumption part - Since here MDBs are consumers, ASA one instance is
free, it will be associated with pending Message in store.

Depending on which App server you are using, if the Messages store is not
persistant, you may have to check if there is a maximum limit on the
duration till which the Message stored will be kept (if so, it shud be there
in vendor documentation). Since all these aspects are QoS features, we need
to referr to specific vendor documentation, which may not be available in
specifications.

Binil

----- Original Message -----
From: "Kamaraj, Pushparaj" <Pushparaj_Kamaraj@(protected)>
To: <J2EEPATTERNS-INTEREST@(protected)>
Sent: Monday, July 19, 2004 2:12 PM
Subject: Re: [SPAM] - Re: Regarding restricting number of instant for MDB -
Found word(s) list error in the Text body.


> Hi,
> Thank you very much Binidas.
>
>      If I explain the scenario it will be better for understanding.
>
>      We have a program, which will do some complex calculation, which
> needs to be triggered asynchronously from screen, and the process may take
> 15 mins to complete. The screen will not wait until the calculation is
> complete. This is the reason we preferred JMS and MDB. The screen event
will
> put the message into the queue and JMS will hand over the message to MDB
for
> processing.
>
>   Is it a correct approach?
>
>      Assume the Object pool size is 5 and there are 6 concurrent users
> are doing the operation which will end up in 6 messages. As the Object
pool
> size is 5, all the pool instant will be used, for 6th message, as there is
> no object is free in the pool the system will instantiated a new one. The
> same way if there are 25 concurrent messages there is a possibility 25
> instant may be running.
>
>   Is my understanding correct?
>
>      The requirement is if the pool size is 5 and already all the
objects
> in the pool is under use then the 6th message needs to wait in the queue
> until one object is returned to the pool. For that what configuration
needs
> to be done?.
>
> Kind regards,
> K.Pushparaj.
>
>
>
> > -----Original Message-----
> > From: Binildas C. A. [SMTP:binil_christudas@(protected)]
> > Sent: Monday, July 19, 2004 12:33 PM
> > To:  J2EEPATTERNS-INTEREST@(protected)
> > Subject:    [SPAM] - Re: Regarding restricting number of instant for
MDB
> > - Found word(s) list error in the Text body.
> >
> > Hi
> >
> > Instead of "If the system start associating a MDB for each message ",
The
> > system will associate some instance of the MDB which is already
available
> > in
> > the pool for each message. This means, for each individual message, we
> > dont
> > end up with each seperate MDB instance. Instead, MDB instances get
reused
> > (Object pooling). This is the very use of using MDB than a standalone
JMS
> > listener(of course, with other features like TX, etc...)
> >
> > Instead of "for each message then there will be many processes running
in
> > parallel" , we can re-write as follows:
> > For each message, container wont start seperate process, and not even a
> > seperate thread. Instead, container will chose a thread from the thread
> > pool, and associate that thread to the chosed MDB context, and the
message
> > will be served by this MDB.
> >
> > Now, to tune the number of MDBs and all - This a task which we need to
do
> > taking into consideration things like:
> >
> > 1. App Server
> > 2. Size of application
> > 3. Other applications in server
> > 4. Frequency of messages
> > 5. Time to serve each message
> > 6...
> > The list goes like this...
> >
> > Binildas
> > Sr. Tech. Architect
> > http://www.infosys.com/setlabs/)
> >
> > ----- Original Message -----
> > From: "Kamaraj, Pushparaj" <Pushparaj_Kamaraj@(protected)>
> > To: <J2EEPATTERNS-INTEREST@(protected)>
> > Sent: Monday, July 19, 2004 12:33 PM
> > Subject: Regarding restricting number of instant for MDB
> >
> >
> > > Hi,
> > >      We are having Message driven bean and other session beans in
the
> > > same container.
> > >      The characteristics of MDB is whenever a message is added to
the
> > JMS
> > > queue it will be instantiated to serve the message.
> > >      We are expecting there will be large number of messages coming
> > to
> > > JMS queue. If the system start associating a MDB for each message then
> > there
> > > will be many processes running in parallel, which will reduce the
system
> > > performance. How to restrict the maximum number of active MDB in the
> > system?
> > > And the configuration should not affect other session bean instants.
If
> > we
> > > restrict the maximum instant to 10, at the most there will be only 10
> > MDBs
> > > and other request will be waiting in the JMS queue.
> > >
> > >      We are using the following configuration to achieve the above
> > > requirement. Is that correct?
> > >
> > > <message-driven-descriptor>
> > >                 <pool>
> > >
> > > <max-beans-in-free-pool>6</max-beans-in-free-pool>
> > >
> > > <initial-beans-in-free-pool>3</initial-beans-in-free-pool>
> > >                 </pool>
> > >           </message-driven-descriptor>
> > >
> > > Thanks,
> > > K.Pushparaj.
> > >
> > > ____________________________________________
> > > Confidential: This electronic message and all contents contain
> > information
> > > from Syntel, Inc. which may be privileged, confidential or otherwise
> > > protected from disclosure. The information is intended to be for the
> > > addressee only. If you are not the addressee, any disclosure, copy,
> > > distribution or use of the contents of this message is prohibited. If
> > you
> > > have received this electronic message in error, please notify the
sender
> > > immediately and destroy the original message and all copies.
> > >
> > > ====================================================================
> > > Companion Site: http://www.corej2eepatterns.com
> > > J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> > > List Archive:
> > http://archives.java.sun.com/archives/j2eepatterns-interest.html
> > > Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> > listserv@(protected)
> > >
> >
> > ====================================================================
> > Companion Site: http://www.corej2eepatterns.com
> > J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> > List Archive:
> > http://archives.java.sun.com/archives/j2eepatterns-interest.html
> > Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> > listserv@(protected)
> >
> ____________________________________________
> Confidential: This electronic message and all contents contain
information
> from Syntel, Inc. which may be privileged, confidential or otherwise
> protected from disclosure. The information is intended to be for the
> addressee only. If you are not the addressee, any disclosure, copy,
> distribution or use of the contents of this message is prohibited. If you
> have received this electronic message in error, please notify the sender
> immediately and destroy the original message and all copies.
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
>

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)