£ and ê in a XML message is parsed successfully in broker but when one of the Queue manager tries to put the output message in another Queue manager, It throws 'Unconvertable character' exception and message goes to dead letter queue.
Channel conversion is turned on and CCSID in both the queue managers is set to '819'.
What shall be done to avoid this?
Need Help on this..!!
Update Nov 15
There is more thing that we can check If we are facing this issue.
I was posting the message from RFHUTIL, and in MQMD tab, value in code page field was set to 457. So this was one of the reasons in faillure.
I posted the same message again with code page value as 819 and then the same XML message worked fine.
So, if you are facing the same issue, you might wanna check the RFHUTIL settings as well.
The mentioned characters doesn't come under CCSID 819.
And as the channel conversion is ON, queue manager will try your message to convert the message into it's own CCSID(819), which will fail to do so as the characters are not supported.
Solutions could be:
1) Turn off channel conversion.
2) Change the CCSID of your queue managers to 1208.
Huge topic data conversion, and it depends on the language you use. A general summary is make sure the codedcharsetid for the message in the MD matches the characters codepoints in the message. Then, make sure when you get the message you get/convert and make sure you are either running in a locale which can display those characters OR put a ccsid in the MD prior to the get. If you use .net or Java then there are implications although the same remains true.
Related
We have a PHP app that forwards messages from RabbitMQ to connected devices down a WebSocket connection (PHP AMQP pecl extension v1.7.1 & RabbitMQ 3.6.6).
Messages are consumed from an array of queues (1 per websocket connection), and are acknowledged by the consumer when we receive confirmation over the websocket that the message has been received (so we can requeue messages that are not delivered in an acceptable timeframe). This is done in a non-blocking fashion.
99% of the time, this works perfectly, but very occasionally we receive an error "RabbitMQ PRECONDITION_FAILED - unknown delivery tag ". This closes the channel. In my understanding, this exception is a result of one of the following conditions:
The message has already been acked or rejected.
An ack is attempted over a channel the message was not delivered on.
An ack is attempted after the message timeout (ttl) has expired.
We have implemented protections for each of the above cases but yet the problem continues.
I realise there are number of implementation details that could impact this, but at a conceptual level, are there any other failure cases that we have not considered and should be handling? or is there a better way of achieving the functionality described above?
"PRECONDITION_FAILED - unknown delivery tag" usually happens because of double ack-ing, ack-ing on wrong channels or ack-ing messages that should not be ack-ed.
So in same case you are tying to execute basic.ack two times or basic.ack using another channel
(Solution below)
Quoting Jan Grzegorowski from his blog:
If you are struggling with the 406 error message which is included in
title of this post you may be interested in reading the whole story.
Problem
I was using amqplib for conneting NodeJS based messages processor with
RabbitMQ broker. Everything seems to be working fine, but from time to
time 406 (PRECONDINTION-FAILED) message shows up in the log:
"Error: Channel closed by server: 406 (PRECONDITION-FAILED) with message "PRECONDITION_FAILED - unknown delivery tag 1"
Solution <--
Keeping things simple:
You have to ACK messages in same order as they arrive to your system
You can't ACK messages on a different channel than that they arrive on If you break any of these rules you will face 406
(PRECONDITION-FAILED) error message.
Original answer
It can happen if you set no-ack option of a Consumer to true that means you souldn't call ack function manually:
https://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.consume.no-ack
The solution: set no-ack flag to false.
If you aknowledge twice the same message you can have this error.
A variation of what they said above about acking it twice:
there is an "obscure" situation where you are acking a message more than once, which is when you ack a message with multiple parameter set to true, which means all previous messages to the one you are trying to ack, will be acked too.
And so if you try to ack one of the messages that were "auto acked" by setting multiple to true then you would be trying to "ack" it multiple times and so the error, confusing but hope you understand it after a few reads.
Make sure you have the correct application.properties:
If you use the RabbitTemplate without any channel configuration, use "simple":
spring.rabbitmq.listener.simple.acknowledge-mode=manual
In this case, if you use "direct" instead of "simple", you will get the same error message. Another one looks like this:
spring.rabbitmq.listener.direct.acknowledge-mode=manual
As far as I understand, the SEME (sender's message reference) attribute of a SWIFT MT message has to be unique per sender (it is the sender's responsibility to ensure uniqueness). So, let's say there are two sending entities A and B and I am the receiver. Then it would be a valid scenario to have both of them send out a SWIFT MT message with the same SEME, right? How could I differentiate messages coming from sender A and B? What is common practice in such a case?
In the documentation (MT 558 in that case) it says:
Reference assigned by the triparty agent to unambiguously identify the
message.
The MIR in the {2: Application Header Block} seems to be the one according to me.
MIR: message input reference, unique identifiers containing the date, logical terminal (including branch code), session and sequence numbers.
Info source: https://www.prowidesoftware.com/about-SWIFT.jsp
I have a WTX map which puts a message on WMQ "Q1". There is some other application which reads the message from "Q1" and then processes the message and places the response on the queue specified in "ReplyToQ" available on MQ Header information.
I am not able to find a command parameter to add the ReplyToQ in the message WTX map is placing on "Q1".
Any thoughts?
Thanks for taking the time to look at this question and helping out!
The ReplyToQueue is sent on the message header, so you must get the message with the header (-HDR) and parse it from there on your input card.
Here's the doc about the adapter's command:
http://pic.dhe.ibm.com/infocenter/wtxdoc/v8r4m1/index.jsp
You should have a type tree on the Examples to read the message with a header.
Regards,
Bruno.
We have developed a flow which does a transformation after it gets the data from DB2 stored procedure. While doing the transformation in MAPPING node of wmb v7.0.0.5 we are facing this un convertible recoverable exception. How to avoid this exception to occur.
By default the the CCSID of your broker will be 819. But, I suspect the message you are posting have some characters which are not supported by CCSID 819.
To resolve this issue, you can set the MQMD.CCSID to 1208 as below:
SET OutputRoot.MQMD.CodedCharSetId = 1208;
However, I faced another issue with publication node. The publication node tries to convert the message into the queue manager's CCSID, before publishing. So, if your queue manager's CCSID is 819(lower CCSID than 1208) and publication node tries to convert the message(which contains special characters not supported by CCSID 819), then an exception will be thrown(unconvertible character).
Above case may also hold for mapping node. To resolve this try setting below:
SET OutputRoot.MQRFH2.(MQRFH2.Field)NameValueCCSID = 1208;
SET OutputRoot.Properties.CodedCharSetId = 1208;
If you can put up a trace, then the exact cause will be clear.
Here's what I'm attempting to do: Let's assume that you are in mail and create a New blank mail message, then enter some data into it, such as body copy, etc. (in my case, the message was created through scripting bridge using the "Mail Contents of this Page" from safari... the main purpose of this process for my application.)
From my application, I want to select that message and assign it to:
MailOutgoingMessage *myMessage;
so that I can programmatically add recipients. I've tried several ways of doing this which seemed logical, but so far I haven't found the right combination, and the header file doesn't seem to be very clear to me (I'm new to scripting bridge.)
My initial thought was to try this:
mailMessage = [[mail outgoingMessages] lastObject];
Which should grab the last outgoing message created. It seems to work in that I am able to add recipients to mailMessage (though there have been a few times that I received unexpected results when multiple outgoing messages exist, such as adding the recipients to the wrong message) but attempting to log the subject line of the message:
NSLog(#"Subject = %#",[mailMessage subject]);
always returns NULL even though there is a subject clearly viewable in the subject field of the message. NULL is returned for any other parameter as well.
I'm gathering it must be a problem with my assignment to mailMessage above, because the only time I receive a NULL for message properties (or receive unexpected results) is if I try to point mailMessage to an existing outgoing message. If I create the mail message with scripting bridge, then I can retrieve all of the properties correctly.
Does anyone understand the hierarchy of the Mail scripting enough to tell me why I am getting NULLs for the parameters using the above assignment for mailMessage? What would the simplest way be go grab my message so that I can add recipients and later call the:
[myMessage send];
method? Any insight would be helpful. I've spent a week going through the mail.h header file and am quite literally at a loss as to what else to try at this point.
There's no way to (send, get or set the properties of the outgoing message) that the user or Safari has created.
It's a bug (it stopped working since Mac OS X 10.4), or some privacy/security considerations.