| Author |
Message
|
| ZiggyDude |
 Posted: Mon Jul 06, 2015 7:07 am Post subject: C# Code Loses Messages |
 |
|
Newbie
Joined: 06 Jul 2015
Posts: 7
|
We have C# code that pulls messages off the queue. It works right when we “Put” a message on the queue using the dialog box to paste text in. When the messages come in from an outside agency we see the messages in the queue but they vanish when the code pulls them off. So we have no messages captured and the Q gets emptied out.
At a total loss to explain this one. Why can we retrieve the XML with the same code after we put - but the code loses the message when they put.
This is an existing system except our side went from version 6.0 to 8.0. So, we know the sender is OK.
OS is Windows Server 2008 R2
Receiving Q is version 8.0
Sending Q is version 7.0.1 |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jul 06, 2015 7:22 am Post subject: Re: C# Code Loses Messages |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| ZiggyDude wrote: |
| We have C# code that pulls messages off the queue. It works right when we “Put” a message on the queue using the dialog box to paste text in. When the messages come in from an outside agency we see the messages in the queue but they vanish when the code pulls them off. |
What does the C# code do? What is it supposed to do?
Are there any errors from the C# code? Any output from the code?
_________________
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 |
|
|
| ZiggyDude |
| Posted: Mon Jul 06, 2015 7:27 am Post subject: |
|
|
Newbie
Joined: 06 Jul 2015
Posts: 7
|
Hi Bruce - thanks for the reply.
We get no errors. The code does a Get. I have pasted it below.
| Code: |
using System;
using System.Net.Mail;
using System.Data.Common;
using PA.DPW.Batch.Core;
using PA.DPW.Batch.Utilities;
using System.Configuration;
using System.IO;
using IBM.WMQ;
namespace PA.DPW.msu.JNT.jnt000
{
/// <summary>
/// Standard client assembly class name and interface.
/// </summary>
public class Program:IBatchClient
{
private MyConfigData myConfigData;
/// <summary>
/// Standard client assembly class name.
/// </summary>
public Program()
{}
#region IBatchClient Members
/// <summary>
/// Implementation of the Default RunBatch method which comes from inheriting <seealso cref="IBatchClient"/>.
/// </summary>
/// <param name="jobName">Name of the job to be run by the client.</param>
public void RunBatch(string jobName)
{
RunBatch(jobName, String.Empty);
}
public void RunBatch(string jobName, string arguments)
{
myConfigData = (MyConfigData)System.Configuration.ConfigurationManager.GetSection(CommonFunctions.GetJobConfigSection());
//verify that destination path exists
if (!Directory.Exists(ConfigurationManager.AppSettings["OutputFolder"]))
{
throw new Exception("Output folder " + ConfigurationManager.AppSettings["OutputFolder"] + " does not exist or cannot be accessed.");
}
ClientLogger.WriteLogEntry(0, "Initializing WebSphere MQ 8.0 QueueManager...");
MQQueueManager mqQMgr;
try
{
mqQMgr = new MQQueueManager(ConfigurationManager.AppSettings["MQSeriesQueueManager"]);
}
catch (MQException mex)
{
ClientLogger.WriteLogEntry(0, "Unable to initialize QueueManager: " + mex.Message);
throw;
}
ClientLogger.WriteLogEntry(0, "WebSphere MQ 8.0 QueueManager Initialized.");
MQQueue mqQueue;
try
{
mqQueue = mqQMgr.AccessQueue(ConfigurationManager.AppSettings["MQSeriesQueue"], MQC.MQOO_INPUT_AS_Q_DEF + MQC.MQOO_FAIL_IF_QUIESCING);
}
catch (MQException mex)
{
System.Console.WriteLine("MQQueueManager::AccessQueue ended with " + mex.ToString());
throw;
}
bool isContinue = true;
int sequence = 1;
while (isContinue)
{
MQMessage mqMsg = new MQMessage();
MQGetMessageOptions mqGetMsgOpts = new MQGetMessageOptions();
mqGetMsgOpts.WaitInterval = 15000;
mqGetMsgOpts.Options |= MQC.MQGMO_WAIT;
try
{
//verify that destination path exists
if (!Directory.Exists(ConfigurationManager.AppSettings["OutputFolder"]))
{
throw new Exception("Output folder " + ConfigurationManager.AppSettings["OutputFolder"] + " does not exist or cannot be accessed.");
}
mqQueue.Get(mqMsg, mqGetMsgOpts);
if (mqMsg.Format.CompareTo(MQC.MQFMT_STRING) == 0)
{
//verify that destination path exists
if (!Directory.Exists(ConfigurationManager.AppSettings["OutputFolder"]))
{
throw new Exception("Output folder " + ConfigurationManager.AppSettings["OutputFolder"] + " does not exist or cannot be accessed.");
}
string fileName = ConfigurationManager.AppSettings["OutputFolder"] + "\\jnetpbb_" + DateTime.Now.ToString("MMddyyyy") + "_" + sequence.ToString() + ".xml";
while (File.Exists(fileName))
{
sequence++;
fileName = ConfigurationManager.AppSettings["OutputFolder"] + "\\jnetpbb_" + DateTime.Now.ToString("MMddyyyy") + "_" + sequence.ToString() + ".xml";
}
var file = File.CreateText(fileName);
file.Write(mqMsg.ReadString(mqMsg.MessageLength));
file.Close();
ClientLogger.WriteLogEntry(0, "Message #" + sequence.ToString() + " was written to " + fileName + " successfully.");
sequence++;
}
}
catch (MQException mex)
{
isContinue = false;
if (mex.Reason == MQC.MQRC_NO_MSG_AVAILABLE)
{
ClientLogger.WriteLogEntry(0, "Queue is now empty.");
isContinue = false;
}
else
{
throw;
}
}
}
mqQueue.Close();
mqQMgr.Disconnect();
}
#endregion
#region Private Methods
#endregion
}
} |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 06, 2015 7:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So if the message is not a string, you do nothing with it.
Also, what line of your debug output do you see, when you run it in your batch mode? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 06, 2015 8:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| So if the message is not a string, you do nothing with it. |
And to underline the valid point made by my most worthy associate, did the sending system move from v6.0 to v8.0 and if not, what constant do they use to set the Format field in the MQMD?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ZiggyDude |
| Posted: Mon Jul 06, 2015 9:14 am Post subject: |
|
|
Newbie
Joined: 06 Jul 2015
Posts: 7
|
Thanks to all for replies.
I did come across one thing different. The XML that we pasted in from the "Put" dialog box was straight simple XML. No pretty formatting. A simple string. The XML that is coming to us has hex values of 0D 0A which I believe is a carriage return and what appears as a period shows up to the right.
If we copy the data from "Browse" to clipboard and paste - the formatting char are gone. But I wonder if that is somehow causing an issue.
The sending system was always 7.0.1 - they have not made any changes. We changed our side from 6.0 to 8.0.
I will try to post an image of the browse to show this.[/img] |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 06, 2015 9:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ZiggyDude wrote: |
| Thanks to all for replies. |
Will you now reply in turn to the question about debug output?
Everything you've posted indicates that the C# application is consuming the messages as expected and simply ignoring them. This could be connected to the value of the MQMD Format (as we've suggested) or the format of the message (as you've suggested).
But the next step is to debug your application like any other. There's nothing MQ specific going on here. It's just an application reacting to input in an unexpected way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 06, 2015 9:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ZiggyDude wrote: |
| The XML that is coming to us has hex values of 0D 0A which I believe is a carriage return |
That's a windows CRLF - line break.
It wouldn't have anything to do with your program dropping messages, unless there's parts where you parse the XML - and you aren't using the MS XML parser, or otherwise can't accept mixed content.
Again, there is no else to
| Code: |
| if (mqMsg.Format.CompareTo(MQC.MQFMT_STRING) == 0) |
So if that's not set, message gets discarded. |
|
| Back to top |
|
|
| ZiggyDude |
| Posted: Mon Jul 06, 2015 9:34 am Post subject: |
|
|
Newbie
Joined: 06 Jul 2015
Posts: 7
|
| I was working on the image - but I would have to cut so much out due to data sensitivity stuff. Basically in the hex char we see "3E 0D 0A 3C" and on the right text side we see ">.<" |
|
| Back to top |
|
|
| ZiggyDude |
| Posted: Mon Jul 06, 2015 9:35 am Post subject: |
|
|
Newbie
Joined: 06 Jul 2015
Posts: 7
|
| Jeff - I will reply to that part. But the developer that has it working on his machine is not in at moment. I am trying to set this up on anotehr box for that. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 06, 2015 9:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ZiggyDude wrote: |
| I was working on the image - but I would have to cut so much out due to data sensitivity stuff. Basically in the hex char we see "3E 0D 0A 3C" and on the right text side we see ">.<" |
Again, 0D 0A is windows line ending. It's the equivalent of /n on Unix.
So you have blank lines between your tags. Once this XML is parsed, it will be treated as "mixed content", i.e. the blank space will be the value of the element in question.
Again, not an issue unless your code somewhere else throws an XML parsing error. |
|
| Back to top |
|
|
| ZiggyDude |
| Posted: Mon Jul 13, 2015 5:19 am Post subject: Thank You |
|
|
Newbie
Joined: 06 Jul 2015
Posts: 7
|
I just wanted to get back to you all and thank you for the time and attention you gave me on this topic.
The hole in the code about the format command was indeed the issue. The developer had pulled it out of some code sample and put it in. The messages failed and were simply lost.
He blames it on the "Format" property not being set by the sender (itis empty in the message browser). Others think it is the formatting in the text. Regardless - it is fixed now.
My thanks to all that participated in the topic. Having another set of eyes really helped!
- Ziggy - |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 13, 2015 5:25 am Post subject: Re: Thank You |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ZiggyDude wrote: |
| Regardless - it is fixed now. |
This is of course good news. Initially you posted:
| ZiggyDude wrote: |
This is an existing system except our side went from version 6.0 to 8.0. So, we know the sender is OK.
|
If it's an existing system, how was it this used to work? Doesn't affect the validity of your solution, but elderly inquiring minds need to know....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ZiggyDude |
| Posted: Mon Jul 13, 2015 5:56 am Post subject: |
|
|
Newbie
Joined: 06 Jul 2015
Posts: 7
|
I am very happy to field any questions.
The existing system was BizTalk (BT) using the MQS Adapter to pull the messages off of the Q and process them. It is a COM+ component and we then DCOM to the BT server. All worked just fine.
We are migrating off of Windows Server 2003 going to 2008R2. With that came the upgrade from MQS 6.0 to 8.0 to stay supported. So, we have a new OS and a new version of MQS.
When we went to MQS 8.0 - we could not get full functionality with the adapter. We could use BT to "put" but not "get". Our server guys came up with something about how the BT adapter only supported MQS up to version 7.x. They tried something from a help article about adding some DLLs - but it was still no go.
Time was running out as they were about to unplug the last of the 2003 boxes.
So, some .NET code was found in samples (MSDN) and the idea was to pull the messages off the Q with that - drop them in a folder - then BT would get the messages. The rest of the process would then proceed the same. Portions of that sample code was used in what you see above. The developer saw the format statement and simply copied it in there.
Things worked just fine. We had a sample message, dropped it in on our side, then BT grabbed it and off we went. But when we got messages from the entity that was sending them to us from their MQS 7.0.1 things went wrong. So, the only things different between our test was:
- Who put the message in
- The version of MQS sending
- The message we dropped was a simple XML string while the ones being sent to us had pretty formatting (all the indents and carriage returns to look nice in notepad or something).
Reading through the various support sites I ruled out any issues with earlier versions of MQS talking to 8.0. I was wondering if we had done something wrong with our MQS install, or any other number of possibilities. After Google after Google I found MQS online chat that did not work but this forum was great.
The remaining mystery to me is why the XML we dropped in on our side worked while the incoming failed. But it failed with that format command.
So - my thanks! |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 13, 2015 6:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ZiggyDude wrote: |
| The remaining mystery to me is why the XML we dropped in on our side worked while the incoming failed. But it failed with that format command. |
The most plausible theory is that the BizTalk adapter you were using previously consumes and processes all messages without reference to any header fields (the behavior of the BizTalk we have in a corner here, whimpering as the IIBv9 bus comes to run it down). So if messages were sent from your 3rd party with a blank MQMD.Format field, it would have read them off and processed them.
When you drop code into the new system with the tool, the format field will indicate it's a string automagically, and hence that code you posted will process it. When the 3rd party messages come in with the blank Format field, your code reads them and they fall through the hole in the code. Remind your developer that while it's unquestionably best practice to set that Format field, a lot of applications don't bother & code should account for these numskulls.
But as long as it's working, this is all pleasantly academic.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
