| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Not another Buffer Question! (VB .net API's) |
« View previous topic :: View next topic » |
| Author |
Message
|
| cavalcade |
 Posted: Thu Nov 09, 2006 11:40 pm Post subject: Not another Buffer Question! (VB .net API's) |
 |
|
Newbie
Joined: 08 Nov 2006
Posts: 6
|
Hi,
Apologies if this is quite n00b like. I've searched the forum and I can see a few pointers for VB6, but nothing for .net, so I'm not sure if this still applies. We have an app from a third party vendor that is crapping out when trying to read a largish message off a queue. The vendor tell us they are using the MQ .net APIs, but not setting any specific buffer parameters (or using the truncate option) on the GET. We're under time pressures to deploy something, so although I think we could get round this by getting the vendor to change the code in the app, I'm not sure we have enough time to regression test all our stuff on a new app version. So my questions:
1) Is there anyway to set a default buffer size for all interactions with a queue manager, or queue. So when .net tries to get a message it defaults to say something set as an environmental variable on the box? My understanding from some research is probably no, however I could be proved wrong.... 
2) If a buffer size isn't passed through the .net API, what is the maximum message size it will accept - does anyone know? Is it 65kb?
3) Does anyone have any experience of this issue, and what workarounds did you use?
Thanks, and if this has been answered before, then feel free to link to the topic and chastise me!  |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Nov 10, 2006 1:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, understand .NET is not my strongest language (though I'm getting there) and take all advice with a pinch of salt.
1) The .NET MQMessage in theory encapsulates the buffer and sizes it automatically. When you say "crapping out" does it give a reason or just fall to it's knees? Is it possible that the vendor code that reads from the buffer has size issues & the MQ code is working? Be this as it may, there is a ResizeBuffer method on that object you may want to look up. I don't believe the object has a constructor that takes an initial size.
2) Again in theory it can handle any message up to the maximum message size for that box (slightly odd if it couldn't)
3) Never tried a message more than about 100Kb through .NET - sorry
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| cavalcade |
| Posted: Fri Nov 10, 2006 1:48 am Post subject: |
|
|
Newbie
Joined: 08 Nov 2006
Posts: 6
|
| Vitor wrote: |
Ok, understand .NET is not my strongest language (though I'm getting there) and take all advice with a pinch of salt.
1) The .NET MQMessage in theory encapsulates the buffer and sizes it automatically. When you say "crapping out" does it give a reason or just fall to it's knees? Is it possible that the vendor code that reads from the buffer has size issues & the MQ code is working? Be this as it may, there is a ResizeBuffer method on that object you may want to look up. I don't believe the object has a constructor that takes an initial size.
2) Again in theory it can handle any message up to the maximum message size for that box (slightly odd if it couldn't)
3) Never tried a message more than about 100Kb through .NET - sorry |
When I say "crapping out" that was a touch vague - it actually pulls back the message but truncates it at a certain point. Which, as I understand it means the vendor probably isn't using the parameter to fail if a truncated message is detected. But your other comments are worrying - we assumed you had to specify a buffer size, but if .net is supposed to handle it automatically, where else could this truncation occur, in the variable it's reading the value into perhaps? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 10, 2006 2:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| cavalcade wrote: |
| ... in the variable it's reading the value into perhaps? |
Hence my comment "Is it possible that the vendor code ... has size issues". I think it's worth just running it past the vendor to prove it's not something obvious like moving the MQMessage into a buffer for processing where the target buffer is fixed and "obviously" large enough to handle any message. If I had £5 for every "obvious" code assumption that had tripped me up I'd have retired by now. Years ago if you include all the assumptions I made myself.... 
Assume that's not the problem. What more detail on the "crapping out" can you provide? I accept you've got a successfully read but truncated message - is it the missing data causing the problem? There should be a warning message somewhere for TRUNCATED_MSG_ACCEPTED (2079) that they can catch. They could then use the actual data size of the message (included in the MQMessage object even if truncated I think) and the ResizeBuffer function I mentioned. Bit clumsy but ought to work.
Unless someone who knows .NET better than more turns up & posts something more helpful. And less helpful would take effort.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| malammik |
| Posted: Fri Nov 10, 2006 8:31 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
