We Keep Coding

IMB PCF agent returns error while inquiring channel status

I have a problem with PCF message agent while inquiring channel in order to obtain informations about hosts connected to a given queue manager. The code of PCFAgent is
MQGetMessageOptions getMessageOptions = new MQGetMessageOptions();
getMessageOptions.options = MQC.MQGMO_BROWSE_NEXT + MQC.MQGMO_NO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING;
messageAgent = new PCFMessageAgent(MQEnvironment.hostname, MQEnvironment.port, MQEnvironment.channel);
and code of options is
inquireOptions = new PCFMessage(CMQCFC.MQCMD_INQUIRE_CHANNEL_STATUS);
inquireOptions.addParameter(CMQCFC.MQCACH_CHANNEL_NAME, "*");
inquireOptions.addParameter(CMQCFC.MQIACH_CHANNEL_INSTANCE_TYPE, CMQC.MQOT_CURRENT_CHANNEL);
inquireOptions.addParameter(CMQCFC.MQIACH_CHANNEL_INSTANCE_ATTRS, new int[]{
CMQCFC.MQCACH_CHANNEL_NAME, CMQCFC.MQCACH_CONNECTION_NAME, CMQCFC.MQIACH_MSGS,
CMQCFC.MQCACH_LAST_MSG_DATE, CMQCFC.MQCACH_LAST_MSG_TIME, CMQCFC.MQIACH_CHANNEL_STATUS
});
responses = messageAgent.send(inquireOptions);
Not always, but occasionally the application resturns an exception that says "Completion Code 2, Reason 2100" and my host (the one on which the application is running) leaves a pending connection on the server that is never closed until the MQManager is restarted.
I've read that this exception is due to a conflict in creating dynamic queues, but in my code I don't create any queue.
Someone could help me? Sorry, I've no previous experiences with queue managers.
Thank you

2100 (MQRC_OBJECT_ALREADY EXISTS) is indeed a problem with creating a dynamic queue.
Explanation
An MQOPEN call was issued to create a dynamic queue, but a queue with the same name as the dynamic queue already exists.
Completion code
MQCC_FAILED
Programmer response
If supplying a dynamic queue name in full, ensure that it obeys the naming conventions for dynamic queues; if it does, either supply a different name, or delete the existing queue if it is no longer required. Alternatively, allow the queue manager to generate the name.
If the queue manager is generating the name (either in part or in full), reissue the MQOPEN call.
Under the covers, the PCFMessageAgent will create a PCF Format message using the details you supply in the PCFMessage and will open a model queue to create a temporary queue in order to receive the reply from the Command Server. These temporary queues are named by the queue manager by producing a unique portion using a timestamp, resulting in a name something like AMQ.5E47207E2227AA02. If you have lots of concurrent applications doing this, it is possible that you could end up with a clash of names, and the second request in, at the same time might get a name conflict.
If you have a way to make the temporary queue name more unique should such concurrency be a problem in your system, you can set the prefix used for the temporary queue name using the setReplyQueuePrefix method. You could, for example, user the user ID each application is running under, if that is unique.
public void setReplyQueuePrefix(java.lang.String prefixP)
Sets the string used as the first part of the agent's reply queue name. The reply queue used by the PCFAgent is a temporary dynamic queue. By default, the reply queue prefix used by the PCFAgent is the empty string (""). When this is used, the name of the reply queue is generated entirely by the queue manager. If the method is called with a prefix specified, then the PCFAgent will pass that prefix to the queue manager whenever it needs to create a temporary queue. The queue manager will then generate the rest of the temporary queue name. This means that the queue manager generates a unique name, but the PCFAgent still has some control. The prefix specified should be fewer than 33 characters. If the prefix contains 33 characters or greater, then this method will truncate the prefix to be 32 characters in length. If the prefix does not contain an asterisk (*) character at the end, then an asterisk will be added to the end.

JMS message listener invoker failed, Cause: Identifier contains invalid JMS identifier character '-': 'x-request-id'

I'm working with JMS and queues (Azure queues) for the first time. I'm required to make a queue where Rubi server would write some data and Java would read it from queue and will do further executions.
This process is working fine locally on my machine. I've created a REST endpoint which is writing data in the queue and once data is written in the queue, the listener would take over and read the data and execute.
When we deploy it to Azure the error I can see in logs which is not letting the Queues start is
Setup of JMS message listener invoker failed for destination 'queue' - trying to recover. Cause: Identifier contains invalid JMS identifier character '-': 'x-request-id'
Zipkin is also present on the Azure server as a distributed tracing system and I guess this x-request-id is related to Zipkin which is creating the problem. I've searched Google for the issue but couldn't understand why its happening.
Following is detailed error message:
[36mc.m.s.l.NextGenRequestLoggingFilter [0;39m [2m:[0;39m
Before request [uri=/services/deal-service/api/v2/deals/ack;headers=
[x-request-id:"2d8d86d7-4fbf-9db6-8e95-28813f21a85c",
x-envoy-internal:"true", x-b3-parentspanid:"a209cdc649b0b890", content-
length:"575", x-forwarded-proto:"http", postman-token:"ad074595-
76a5-474b-9711-7e071b12b3b0", x-b3-sampled:"1", x-forwarded-
for:"10.244.2.1", accept:"*/*",
authorization: "some-token-YJc4tg--34jPRziJNSACqNQ", x-b3-
traceid:"6b40ff22781be67ba209cdc649b0b890", x-b3-
spanid:"702684ddb62cfe6b",
host:"portal-gateway.52.228.65.225.nip.io",
cache-control:"no-cache", accept-encoding:"gzip, deflate, br",
user-agent:"PostmanRuntime/7.22.0",
Content-Type:"application/xml;charset=UTF-8"]]
2020-02-18T15:19:34.197666458Z [2m2020-02-18 15:19:34.197[0;39m .
[32mDEBUG
[,6b40ff22781be67ba209cdc649b0b890,702684ddb62cfe6b,true][0;39m .
[35m9[0;39m [2m---[0;39m [2m[ XNIO-1 task-15][0;39m

Section 3.5.1 of the JMS 2 specification states this about message properties:
Property names must obey the rules for a message selector identifier. See
Section 3.8 “Message selection” for more information.
In regards to identifiers, section 3.8.1.1 states, in part:
An identifier is an unlimited-length character sequence that must begin with a Java identifier start character; all following characters must be Java identifier part characters. An identifier start character is any character for which the method Character.isJavaIdentifierStart returns true. This includes '_' and '$'. An identifier part character is any character for which the method Character.isJavaIdentifierPart returns true.
If you pass the character - into either Character.isJavaIdentifierStart or Character.isJavaIdentifierPart the return value is false. In other words, the - character in the name of a message property violates the JMS specification and therefore will cause an error.

From the error message its obvious that you are using qpid JMS client for communication through queues.
qpid client won’t allow any keys which violates java variable naming convention e.g. you won’t be able to send x-request-id in a queue’s header
which qpid jms client is consuming as it’ll throw error.
You need to take care of istio/zipkin to not to add certain headers (id you don’t need them actually) with the queue when its trying to communicate on azure bus.
So you have to disable the istio/zipkin libraries to intercept the request for queues so that request to/from queue can be made without headers. This will fix the issue.

Details of error (Java stack trace) would be really useful here.
By error message I assume, you are using qpid JMS client, that is performing check of message properties' names. These names can contain only characters, that are valid Java identifier characters.
In string 'queue-name' there is a '-' character, that is not Java identifier. To fix, you need to change 'queue-name' into something with valid characters, for example 'queue_name' (with underscore), or 'queueName' (camel case).

Parse byteBuffer in Websphere MQ Exit

I'm trying to build a custom mq exit to archive messages that hit a queue. I have the following code.
class MyMqExits implements WMQSendExit, WMQReceiveExit{
#Override
public ByteBuffer channelReceiveExit(MQCXP arg0, MQCD arg1, ByteBuffer arg2) {
// TODO Auto-generated method stub
if ( arg2){
def _bytes = arg2.array()
def results = new String(_bytes)
println results;
}
return arg2;
}
...
The content of the message (header/body) is in the byte buffer, along with some unreadable binary information. How can I parse the message (including the body and the queue name) from arg2? We've gone through IBM's documentation, but haven't found an object or anything that makes this easy.

Assuming the following two points:
1) Your sender application has not hard coded the queue name where it puts messages. So you can change the application configuration to send messages to a different object.
2) MessageId of the archived message is not important, only message body is important.
Then one alternative I can think of is to create an Alias queue that resolves to a Topic and use two subscribers to receive messages.
1) Subscriber 1: An administratively defined durable subscriber with a queue provided to receive messages. Provide the same queue name from which your existing consumer application is receiving messages.
2) Subscriber 2: Another administratively defined durable subscriber with queue provided. You can write a simple java application to get messages from this queue and archive.
3) Both subscribers subscribe to the same topic.
Here are steps:
// Create a topic
define topic(ANY.TOPIC) TOPICSTR('/ANY_TOPIC')
// Create an alias queue that points to above created topic
define qalias(QA.APP) target(ANY.TOPIC) targtype(TOPIC)
// Create a queue for your application that does business logic. If one is available already then no need to create.
define ql(Q.BUSLOGIC)
// Create a durable subscription with destination queue as created in previous step.
define sub(SB.BUSLOGIC) topicstr('/ANY_TOPIC') dest(Q.BUSLOGIC)
// Create a queue for application that archives messages.
define ql(Q.ARCHIVE)
// Create another subscription with destination queue as created in previous step.
define sub(SB.ARCHIVE) topicstr('/ANY_TOPIC') dest(Q.ARCHIVE)
Write a simple MQ Java/JMS application to get messages from Q.ARCHIVE and archive messages.

A receive exit is not going to give you the whole message. Send and receive exits operate on the transmission buffers sent/received by channels. These will contain various protocol flows which are not documented because the protocol is not public, and part of those protocol flows will be chunks of the messages broken down to fit into 32Kb chunks.
You don't give enough information in your question for me to know what type of channel you are using, but I'm guessing it's on the client side since you are writing it in Java and that is the only environment where that is applicable.
Writing the exit at the client side, you'll need to be careful you deal with the cases where the message is not successfully put to the target queue, and you'll need to manage syncpoints etc.
If you were using QMgr-QMgr channels, you should use a message exit to capture the MQXR_MSG invocations where the whole message is given to you. If you put any further messages in a channel message exit, the messages you put are included in the channel's Syncpoint and so committed if the original messages were committed.
Since you are using client-QMgr channels, you could look at an API Exit on the QMgr end (currently client side API Exits are only supported for C clients) and catch all the MQPUT calls. This exit would also give you the MQPUT return codes so you could code your exit to look out for, and deal with failed puts.
Of course, writing an exit is a complicated task, so it may be worth finding out if there are any pre-written tools that could do this for you instead of starting from scratch.

I fully agree with Morag & Shashi, wrong approach. There is an open source project called Message Multiplexer (MMX) that will get a message from a queue and output it to one or more queues. Context information is maintained across the message put(s). For more info on MMX go to: http://www.capitalware.com/mmx_overview.html
If you cannot change the source or target queues to insert MMX into the mix then an API Exit may do the trick. Here is a blog posting about message replication via an API Exit: http://www.capitalware.com/rl_blog/?p=3304

This is quite an old question but it's worth replying with an update that's relevant to MQ 9.2.3 or later. There is a new feature called Streaming Queues (see https://www.ibm.com/docs/en/ibm-mq/9.2?topic=scenarios-streaming-queues) and one of the use-cases it is designed to support is putting a copy of every message sent to a given queue, to an alternative queue. Another application can then consume the duplicate messages and archive them separately to the application that is processing the original messages.

Apache Camel multicast routes interfering with each other

I am using a multicast in Camel DSL because I need to send a copy of the same message to two different endpoints. However, it seems that the routes are interfering with each other. Have I got the syntax wrong, or some other issue?
from("{{in.endpoint}}")
.routeId(this.getClass().getSimpleName())
.multicast().parallelProcessing()
.to("{{update.in}}", "{{add.ibmmq.topic}});
where
in.endpoint = seda:addOrder?waitForTaskToComplete=Never
update.in = seda:updateData?waitForTaskToComplete=Never
add.ibmmq.topic = an ibmmq topic
I expect the 'update' route to receive the 'in' message, and the 'ibmmq topic' to receive the same message, presumably cloned. However, in the logs I am getting exceptions like:
Exchange[
Id ID-slon12d10628-1228-1386074869307-0-44746
ExchangePattern InOnly
Headers {breadcrumbId=ID-slon12d10628-1228-1386074869307-0-41682, calendar=null, CamelMyBatisResult=[integration.model.EInquiry#19eb77c, integration.model.EInquiry#12059ce, xxxxxxx
BodyType message.BulkAddOrderMsg
Body message.BulkAddBondOrderMsg#77df22
]
but the EInquiry objects are read in by a completely separate route, nothing to do with this route except it, too, sends messages to 'in.endpoint'.
The other thing is because I read from Tibco and send to IBMMQ, I have to clear the JMS header codes because they are not compatible, so I have put:
exchange.getIn().getHeaders().clear();
in my 'update' route. Could this be clearing Camel's exchange tracing headers and causing this issue, basically like some weird concurrency issue?

Its hard to find the error without full source code, but bear in mind that multicast does not do deep copy.
If you have child objects in the Order object they are not duplicated and they are shared between both SEDA routes.
Probably you will have to make a custom deep clone of the object

The body of your Exchange is a custom POJO: message.BulkAddBondOrderMsg#77df22... which means there is no deep cloning available unless you add it. Same thing would happen if the body were DOM XML node...
Serialize the POJO to a String prior to the multicast so it can be shared across Exchanges.

Critical RabbitMQ method arguments

I'm trying to read up and understand 3 fundamental methods in the RabbitMQ Java client:
Channel#basicConsume
Channel#basicPublish; and
DefaultConsumer#handleDelivery
These methods have several arguments that are cryptic and mysterious, and although the Javadocs do provide some explanation of what they are, don't really make it clear/obvious as to what these arguments do:
Channel#basicConsume
consumerTag - a client-generated consumer tag to establish context
noLocal - true if the server should not deliver to this consumer messages published on this channel's connection
exclusive - true if this is an exclusive consumer
arguments - a set of arguments for the consumer
Channel#basicPublish
exchangeName - the exchange to publish the message to
routingKey - the routing key
DefaultConsumer#handleDelivery
envelope - packaging data for the message
These methods, and using them correctly, are crucial to using RabbitMQ in its simplest form (basic publishing & consuming of messages to and from a queue). Until I understand what these arguments are - and what they imply/do on the server-side - I'm stuck and unsure of how to proceed with the library.
Can some battle-weary RabbitMQ veteran help a newbie like myself understand these 7 method arguments, and what they are used for? The Javadoc explanations just aren't clear enough. For example: "arguments - a set of arguments for the consumer". What?!?! Or: "exclusive - true if this is an exclusive consumer"...well what's an exclusive consumer?!?! Etc. Thanks in advance!

Follow below two link :-
https://www.rabbitmq.com/ttl.html
http://www.rabbitmq.com/amqp-0-9-1-quickref.html
Java creates a queue in which messages may reside for at most 60 seconds:
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-message-ttl", 60000);
channel.queueDeclare("myqueue", false, false, false, args);

To throughly understand the implementation of RabbitMQ you might have to go through the AMQP protocol specification and reference. In general irrespective of the language the specification should explain all the parameters
Below link explains about consumer-tag
Exclusive:
Exclusive queues may only be accessed by the current connection, and are deleted when that connection closes. Passive declaration of an exclusive queue by other connections are not allowed.
The server MUST support both exclusive (private) and non-exclusive (shared) queues.
The client MAY NOT attempt to use a queue that was declared as exclusive by another still-open connection. Error code: resource-locked
Customer tag:
Specifies the identifier for the consumer. The consumer tag is local to a channel, so two clients can use the same consumer tags. If this field is empty the server will generate a unique tag.
The client MUST NOT specify a tag that refers to an existing consumer. Error code: not-allowed
The consumer tag is valid only within the channel from which the consumer was created. I.e. a client MUST NOT create a consumer in one channel and then use it in another. Error code: not-allowed
AMQP extensions to understand additional Args (Map)
http://www.rabbitmq.com/extensions.html
Example - TTL:
Per-Queue Message TTL
The x-message-ttl argument to queue.declare controls for how long a message published to a queue can live before it is discarded. A message that has been in the queue for longer than the configured TTL is said to be dead. Note that a message routed to multiple queues can die at different times, or not at all, in each queue in which it resides. The death of a message in one queue has no impact on the life of the same message in other queues.
The server guarantees that dead messages will not be included in any basic.get-ok or basic.deliver methods. Further, the server will try to reap messages at or shortly after their TTL-based expiry.
The value of the x-message-ttl argument must be a non-negative 32 bit integer (0 <= n <= 2^32-1), describing the TTL period in milliseconds. Thus a value of 1000 means that a message added to the queue will live in the queue for 1 second or until it is delivered to a consumer. The argument can be of AMQP type short-short-int, short-int, long-int, or long-long-int.
This example in Java creates a queue in which messages may reside for at most 60 seconds:
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-message-ttl", 60000);
channel.queueDeclare("myqueue", false, false, false, args);
The original expiry time of a message is preserved if it is requeued (for example due to the use of an AMQP method that features a requeue parameter, or due to a channel closure).
Setting x-message-ttl to 0 causes messages to be expired upon reaching a queue unless they can be delivered to a consumer immediately. Thus this provides an alternative to basic.publish's immediate flag, which the RabbitMQ server does not support. Unlike that flag, no basic.returns are issued, and if a dead letter exchange is set then messages will be dead-lettered.
Per-Message TTL
A TTL can be specified on a per-message basis, by setting the expiration field in the basic AMQP class when sending a basic.publish.
The value of the expiration field describes the TTL period in milliseconds. The same constraints as for x-message-ttl apply. Since the expiration field must be a string, the broker will (only) accept the string representation of the number.
When both a per-queue and a per-message TTL are specified, the lower value between the two will be chosen.
This example in Java publishes a message which can reside in the queue for at most 60 seconds:
byte[] messageBodyBytes = "Hello, world!".getBytes();
AMQP.BasicProperties properties = new AMQP.BasicProperties();
properties.setExpiration("60000");
channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);