Recently I attended an interview, he asked this question
I am putting messages in Q. Manager, but client unable to get that messages, what is the problem can you explain it?
(All permission are ok, and put and get are enable state).
There are a 101 possible reasons. That is why MQ provides an MQRC back to the application, and further information in the AMQERR01.LOG. Without either of those you cannot even begin to guess. (P.S. I suspect that would have been a suitable reply in an interview!!)
But, since you ask for us to guess, here's a few more different from those Valerie suggested.
Perhaps the client channel max message length is shorter than the messages on the queue.
The codepage between client and queue manager may be such that data cannot be converted.
Client application get buffer isn't big enough
Hasn't specified accept truncated and the message was bigger than the buffer
AMS is in use and he's not the intended recipient (different from permissions)
This is a very broad question, would need to check error code received by client. Could be programming situation where client is getting based on a specific message or correl ID that does not exist. Could be that channel auth is blocking client. Also, it could be that the putting application did not commit the messages so they are not really available for the get.
Related
I am building a new application that receives data from a number of external devices and needs to make it available to a number of different components. ZeroMQ seems purpose-built for the "data bus" aspect of my architecture.
I recently became aware that zmq STREAM sockets can connect to native TCP sockets and send/received messages. Using zmq throughout has a lot of appeal, but I have one problem that I don't know how to get around.
One of my devices needs to be set up. That is, I connect a socket to it, send it some configuration information, then sit back and wait for it to send me data. The device also has a "reset" capability (useful in some contexts), that requires re-sending the configuration information. Doing this depends upon having visibility to the setup/tear-down stage of the socket interface. I need to know when a new connection is established, so I can send the necessary configuration messages.
It seems that zmq is purposely designed to shield me from that knowledge. Is there a way to do what I want? Or should I just use regular sockets for this interface?
Well, it turns out that reading (the right version of) the fine manual can be instructive.
When a connection is made, a zero-length message will be received by the application. Similarly, when the peer disconnects (or the connection is lost), a zero-length message will be received by the application.
I guess all that remains is to disambiguate between connect and disconnect. Still looking for advice from the community, if others have dealt with this situation before.
Following up on your own answer, I would hesitate to rely on that zero length connect/disconnect message as your whole strategy - that seems needlessly fragile. It's not clear to me from your question which end is persistent and which end needs configuration information, but I expect that one end knows it's resetting and reconnecting, and that end needs configuration information from the peer, so it should ask for it with a message when it needs it, to which the peer responds with the requested information.
If the peer does not yet have the required configuration information before it receives some other message, it could either queue up that work or it could respond back with the need for the config, and then have the rest of the network handle that need appropriately.
You shouldn't need stream/tcp sockets to make that work, it should work with more standard ZMQ socket types, you just need to build the robustness into your application rather than trying to get it for free from TCP/socket actions.
If I've missed your point, and what I'm suggesting won't work for some reason, you will have to give more specific information about your network topology for anyone else to understand what a suitable solution might be.
Is it possible to keep a history of messages (with message content would be perfect) that have already been retrieved and are no longer on a queue?
In the application I can see when the sender attempts to put the message in the queue and when the receiver attempts to pick the messages up, but I'd like to see when the message really arrived into the queue and when the messages were really received.
Does MQ Explorer have this function? How would I use it?
What you are looking for is a message tracking/auditing software for IBM MQ. You can find a list of what is available here.
It is possible to use an API exit to make copies of messages in a queue or to audit both PUT and GET operations.
It is also possible to put messages to a topic, then create as many administrative subscriptions to destination queues as required. Something can then GET and log messages from one of those destination queues. The problem with this is that MQ changes the message ID between publication and consumption whereas in a queue it remains static.
There is no native MQ function to capture messages. It's possible to use linear logs and later scrape the logs but these do not necessarily capture all messages due to optimization. (A message PUT to a waiting getter outside of syncpoint for example.) However there is at least one commercial product to scrape linear transaction logs to audit message activity.
The philosophy of MQ in general is that it is the delivery mechanism and deals with envelope data to route and deliver but does not deal with payload data. WAS, IIB and other broker/transformation engines are where IBM has put all of the functions that deal with message payloads.
We're having this weird problem with Twilio SMS messages hanging with status.
We have tried sending from different Twilio phone numbers to make sure it isn't a problem with that particular number being blocked and none of them go through.
Our system uses SMS messages in the standard form of two-step authentication with a code and a short message to the user inside the SMS body.
The carrier that the message sent is failing is Tune Talk (A Malaysian one).
The error in the Twilio Logs/Console I see is:
Status: Undelivered
Error: (Error: 30008) Unknown error. None
Message SID if it's in any way useful is: SM1024a2d519cf4f6bbfcbc838587cb2af
Any insight on why this is happening would be greatly welcomed.
We had also the same issue with phones that used to receive messages.
The problem is carrier blocking/filtering.
Every carrier uses different filters.
Some carriers block messages with 90% the same content, others use rate filtering (1 message per second or more) others use a combination. The blocking is not forever thought.
Twilio gives the following possible solutions:
Check that the phone you were sending to is turned on and can receive SMS
Ensure that the phone is not roaming off network. We cannot
guarantee message delivery on roaming phones.
Try sending to other phones who have the same mobile carrier.
If messages to other phones go through, the issue is likely device
related. Try rebooting the device or contact the mobile carrier for
help.
If you are sending SMS from an alphanumeric sender ID, see if using
a Twilio phone number works better. We’ve observed that certain
networks may block alpha sender IDs.
Try sending a shorter message to the phone, with simple content that
does not include any special characters. This would give our support
team an idea as to whether the failure is related to concatenation
or character encoding.
Twilio support can help investigate what went
wrong with our carriers. Please open a support request and include a
minimum of 3 or more message SIDs where a 30008 error was thrown.
Per our carriers' requirements, these SIDs can be no older than 48
hours at most.
Check -> Error 30008
Another solution is to use a 5digit code phone number.
Boris, error 30008 is certainly less descriptive than one would hope. In this case, it would be best to send that Message Sid along to support where we can dig a little deeper into the specifics.
Though it doesn't sound like it in this case, if there were a problem with your code, you could check out a production ready account verification tutorial here.
Came here because of exactly the same problem. I have someone who successfully received SMSes just 12 days ago, using the same Australian number, getting a 30008 for every attempt to send to them today. That's a really average-quality error message right there.
The user states that they ported the number from Telstra to Vodafone, but that was 3 months ago. I'm guessing that the forwarding is broken:
http://www.commsalliance.com.au/__data/assets/pdf_file/0013/2326/G565_2009.pdf
In particular:
1.4.4 Where internationally originated SMS is supported donor routing
must be supported wherever bilateral agreement exists for the
national leg, as international networks are not likely to access an
Australian mobile number portability database prior to routing the
message. However, certain limitations apply – see Appendix A.
Since Twilio aren't sending from an Australian number, they probably aren't looking through the number portability database. This would be my suspect cause for any failure to SMS route to a country with number portability.
I've had some of these errors when doing MMS's.
If I look at the detail in the Twilio console, there is additional detail and a secondary error message "12300 Invalid Content-Type. Attempt to retrieve MediaUrl returned an unsupported Content-Type."
I was putting images up on S3, but not setting the Content-Type of the image when I put it on S3.
In my case, the problem was that I was including a website URL in the message.
Once I removed it (replaced it with a simple name) it worked.
I'm not sure whether the issue was the URL itself (e.g. the network considers it spam) or the fact that it contained characters like /.
I am relatively new to JMS and I have been reading a lot on it lately.
I am planning to design a web app which would do the following:
User logs into the system and publishes a message/question to a topic.
All the users who have subscribed to the topic read the message/question and reply to it.
The originator reviews all the answers and picks the best answer.
The originator now replies to only the user whose answer he/she picked and asks for further clarification.
The responder gets the message and replies.
So, once the originator has picked the answer, the JMS now becomes a request/reply design.
My questions are:
Is it possible to publish to a topic with setJmsReplyTo(tempQueue)?
Can request/reply approach be async?
Is it a good idea to have per user queue?
These questions might some dumb to some of the experts here, but please bare in mind that I am still learning.
Thanks.
Is it possible to publish to a topic with setJmsReplyTo(tempQueue)?
You should be able but I'm not 100% sure about it. By the way, I searched in my bookmarks and found this link that should explain what you have to do to build up a Request/Response system using JMS
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
Can request/reply approach be async?
A message listener is an object that acts as an asynchronous event handler for messages. So you approach about request/reply, if using JMS, is by default async.
http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/prog_model.html#1023398
Is it a good idea to have per user queue?
I don't know how many user you expect to have but having one queue for each user is not a good way to handle the messages. I had a problem similar to yours but we used a single queue for each of the macro area and we structured the message to hold the information of the user that sent it in order to store the information later and use it to further analysis.
JMSReplyTo is just a message header, nothing else. So It is possible to publish a message withing a topic with specific value in this header.
Sure! If you would like to create a scalable system you should design event driven system using async instead of blocking aproach. MessageListener can help you.
It is specific to JMS broker implementation. If queue creation is quite cheap there is no problems with such a solution.
I am working with someone who is trying to achieve a load-balancing behavior using JMS Queues with IBM Websphere MQ. As such, they have multiple Camel JMS consumers configured to read from the same Queue. Despite that this behavior is undefined according to the JMS spec (last time I looked anyway), they expect a sort of round-robin / load-balancing behavior. And, while the spec leaves this undefined, I'm led to believe that the normal behavior of Websphere MQ is to deliver the message to only one of the consumers, and that it may do some type of load-balancing. See here, for example: When multi MessageConsumer connect to same queue(Websphere MQ),how to load balance message-consumer?
But in this particular case, it appears that both consumers are receiving the same message.
Can anyone who is more of an expert with Websphere MQ shed any light on this? Is there any situation where this behavior is expected? Is there any configuration change that can alleviate this?
I'm leaning towards telling everyone here to use the native Websphere MQ clustering facility and go away from having multiple consumers pointing at the same Queue, but that will be a big change for them, so I'd love to discover a way to make this work.
Not that I'm a fan of relying on anything that's undefined, but if they're willing to rely on IBM specific behavior, I'll leave that up to them.
The only way for them to both receive the same messages are:
There are multiple copies of the message.
The apps are browsing the message without a lock, then circling back to delete it.
The apps are backing out a transaction and making the message available again.
The connection is severed before the app acknowledges the message.
Having multiple apps compete for messages in a queue is a recommended practice. If one app goes down the queue is still served. In a cluster this is crucial because the cluster will continue to direct messages to the un-served queue instance until it fills up.
If it's a Dev system, install SupportPac MA0W and tell it to trace just that one queue and you will be able to see exactly what is happening.
See the JMS spec in section 4.4. The provider must never deliver a second copy of an acknowledged message. Exception is made for session handling in 4.4.13 which I cover in #4 above. That's pretty unambiguous and part of the official spec so not an IBM-specific behavior.