|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Setting Buffer size after MQGET |
« View previous topic :: View next topic » |
Author |
Message
|
fjb_saper |
Posted: Mon Sep 15, 2008 7:19 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
bruce2359 wrote: |
If you are mqgetting a message from a queue, it is a local queue, AND the message has already traversed your network to get to the local queue. |
Not necessarily. You need to think here MQ Client. Each browsed message will still need to go through the wire to get from the server to the client... _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Sep 15, 2008 7:35 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
I agree.
But this would be an example of writing a program to fit the environment (the application runs on a client platform). If the application were to become a server-bindings application in the future, the code would work, but would 'waste' resources because the environment had changed - but not the application. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
dkeister |
Posted: Mon Sep 15, 2008 7:35 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002 Posts: 184 Location: Purchase, New York
|
Yea, it is a client application so I'm concerned about network traffic more than a given machine's resource... used to be 20 characters in, 120 out (width of a typewriter line)...
However, it is hard to get over the 'memory is cheap' syndrome.
(As an aside, my father designed the switching system for Bell Labs/AT&T and they used to discuss "Will cost of memory ever get down to $1.00 a bit?"
That was in the days of vacuum tube memory. I told him he needed to think to the future... joke is on me. He said "We didn't have computers when I was growing up, so we invented them!")
Hope I'm never to old to learn... _________________ Dean Keister |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Sep 15, 2008 7:42 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
There are issues with client applications. Network performance is one of them. The WMQ Clients manual is a great place to start. Do searches here, too.
For a heavily used application, or, like yours, an application that must deal with large messages, I'd be looking to convert the client-end to a qmgr. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
dkeister |
Posted: Mon Sep 15, 2008 7:53 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002 Posts: 184 Location: Purchase, New York
|
Well, my application is actual a testing application that connects to multiple queue managers concurrently and lets you open multiple queues on each queue manager.
After that you can get/put/move/copy/edit/save/restore messages. Problems I have encountered with large messages is centered around the browse function. When I browse a queue, I don't know how many, how big, or where on the network the QM is. So, I build a browse list by browsing/displaying only the first 200 characters of a message. Some (misbehaved) applications use the queue as a storage mechanism and have thousands of messages on the queue.
I found when I had 10,000 or 20,000 messages of 5000 characters on the queue, creating the browse list took forever. When I accepted truncated and had a 200 character buffer, it was reasonable. The user can then peruse the browse list looking at the first 200 characters help select 'the message'.
Hope that clarifies where I am coming from...
Thanks for the dialogue. _________________ Dean Keister |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Sep 15, 2008 7:57 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Yes, it does. And you are having more fun than I am. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
dkeister |
Posted: Mon Sep 15, 2008 8:01 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002 Posts: 184 Location: Purchase, New York
|
To paraphrase Arthur Dent "... ah, a new use of the word FUN which I haven't been previously exposed to!" _________________ Dean Keister |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Sep 15, 2008 8:08 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
May I inquire: what type of application is this? banking? inventory? sales? gaming? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
dkeister |
Posted: Mon Sep 15, 2008 10:20 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002 Posts: 184 Location: Purchase, New York
|
An application to be able to flexibly test MQ based applications (MQExerciser). Somewhat similar to RFHUtil but makes simultaneous client connections to multiple queue managers, and can have multiple queues open at the same time. So, for example, if you have the text for a message you want to put onto a queue, you can type it in, or read it from a file. Your application may take that message and put messages on one or more output queues. With MQExerciser, you can see all the queues at the same time, browse their contents, view queue depths over time, etc. I think it has a lot of other neat features...
If you want a copy, contact me off line (dkeister@centerprise.com) _________________ Dean Keister |
|
Back to top |
|
 |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|