Author |
Message
|
gblewis |
Posted: Tue Sep 21, 2004 6:59 am Post subject: Setting user parms for MQ |
|
|
Newbie
Joined: 21 Sep 2004 Posts: 4
|
Can anbody help me with an explanation of the parms I can set when placing messages on a que, i.e., persisteance, how long to keep the msgs and such. Are the typically set when the que is created or can they be set by a user putting msgs on to the que. The application is placing xml encoded weather msgs on a que for another app which gets them for processing. Thanks |
|
Back to top |
|
 |
PGoodhart |
Posted: Tue Sep 21, 2004 7:05 am Post subject: |
|
|
Master
Joined: 17 Jun 2004 Posts: 278 Location: Harrisburg PA
|
You are going to find that most of these settings depends on the applications and business processes supported. In your case, given the very limited information you have provided, you might want to consider non-persistant messages, and set the expiration to remove the messages once the data is stale. You can set most options as defaults on the queue or at message put time (runtime). The runtime options override the defaults. _________________ Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
Back to top |
|
 |
gblewis |
Posted: Tue Sep 21, 2004 7:50 am Post subject: |
|
|
Newbie
Joined: 21 Sep 2004 Posts: 4
|
Additional info. The applications doing the putting and getting are written in java. Is there somewhere I could look to see what all the available parms are? |
|
Back to top |
|
 |
PGoodhart |
Posted: Tue Sep 21, 2004 8:44 am Post subject: |
|
|
Master
Joined: 17 Jun 2004 Posts: 278 Location: Harrisburg PA
|
Look at the Using Java, Application Programming Reference and Application Programming Guide. They have almost all of the information that you need to start making the judgement calls when you design your application.
You may want to search the Java forum here and see if you can find some recommendations. I'll also add that you will want to look at JMS and not the "Standard" Java MQ API. The MQ Java API is really there to quickly put testing applications together. The JMS is intended as a much more robust implementation. _________________ Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Sep 21, 2004 9:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
PGoodhart wrote: |
I'll also add that you will want to look at JMS and not the "Standard" Java MQ API. The MQ Java API is really there to quickly put testing applications together. The JMS is intended as a much more robust implementation. |
That's not true.
The JMS API is intended for supplying JMS functionality to a fully J2EE application.
The Java API is intended for supplying FULL MQ access to a Java program, regardless of what environment that program is running in.
I have written several robust, production applications that use the Java API. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PGoodhart |
Posted: Tue Sep 21, 2004 11:21 am Post subject: |
|
|
Master
Joined: 17 Jun 2004 Posts: 278 Location: Harrisburg PA
|
Not to put too fine a point on it, but while it is fully possible to build standard Java API apps that are both robust and fully production ready, which one JMS or Standard API is going to work under heavy load with minimum programming work? Also my understanding that using the JMS implementation provides a number of scalablity and performance advantages (such as connection pooling) that you would otherwise have to implement yourself. Frankly, I think this is more of an application level decision that ideally the developer would make themselves. However, I don't think a JMS J2EE implementation is the wrong path regardless. Honestly if you wanted "fast" you'd write the application in some other language. (VB.Net being faster to implement, and C++ being faster in application performance). Java is a good compromise. _________________ Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
Back to top |
|
 |
|