We are using Istio/Zipkin as a tracing system on our server to add the dynamic headers through Istio sidecar proxy for tracing the request later on using Zipkin. Is there anyway we could disable istio for a certain request.
Problem is, we are working with JMS queues, and when JMS listener tries to listen to a certain queue, it sees the headers like x-request-id added by the istio dynamically and it gives an error (as it'll accept header keys only in camelCase or with underScore or $). We can change header keys added by istio, so we want either istio to not to add headers in some specific requests (the one queue is making).
I've searched google but couldn't find anything about it.
Following is the error message we are getting:
Setup of JMS message listener invoker failed for destination 'queue' - trying to recover.
Cause: Identifier contains invalid JMS identifier character '-': 'x-request-id'
Related
I have an UI application (displays streaming) which makes a WebSocket connection to the Spring Boot microservice (multiple JVM'S) and this service forwards the request to one of the upstream servers and listens to the responses on a JMS queue coming from upstream server, which then response messages had to be returned to the socket.
Issue we are facing is since the socket is point to point, and the Spring Boot application is running on multiple instances which all are listening to the same JMS queue we are unable to serve the data back to the WebSocket when a message is received on a instance which the request to upstream wasn't made.
Here's the basic flow:
WebSocket -> instance1, instance2, instance3 -> Data provider
Instance1 made the request to data provider.
Data provider sends the data back to the queue
Instance 3 receives the message, but it doesn't have the socket connection to send the data back.
We had an interim solution using correlation id in JMS headers and selectors on the queue however now the data publisher is not able to provide the correlation id to depend on.
Does anybody have a better suggestion to address this?
Since you're using a request/reply pattern with JMS you must either use a correlation ID or a unique temporary queue for the response.
You indicated that, "the data publisher is not able to provide the correlation id to depend on." However, your application actually provides the correlation ID. The "data provider" in this case just needs to take it from the message it receives and put it into the response message. The process only requires 2 method calls by the "data provider" - javax.jms.Message.getJMSCorrelationID and javax.jms.Message.setJMSCorrelationID.
If the "data provider" can't do this then it's doubtful they will be able to accomplish the other option of using a unique temporary queue for the response. However, it's worth explaining in any case. When one of your "instance" servers sends the request message it first needs to use javax.jms.Session.createTemporaryQueue to create a temporary queue and then take the return parameter of that method and set it on the request message using javax.jms.Message.setJMSReplyTo. When the "data provider" receives the message they will get this value using javax.jms.Message.getJMSReplyTo and then send the response to this queue where the "instance" will then retrieve it.
These are the two generally accepted ways to implement a request/response pattern with JMS. I don't know of any other ways to implement such a pattern.
I am trying to send a file through postman with a POST request and that file needs to be saved in the local FS. I tried all the 4 options GetHttp,InvokeHttp,ListenHttp,HandleHttpRequest. Seems like GetHttp,InvokeHttp requires a webservice to be running at the end who is sending the POST request, that would not fit our case use case. I tried using ListenHttp but I am not able to change the default hostname option which it is pointing to localhost. Is there a way to change that?
And I tried using HandleHttpRequest as well, and it seems like the client who is receiving the request should send an acknowledgement to end the connection at the sender side, nifi user guide doesn't provide an example on how to use or configure that. Can someone provide me an example for the use case which I mentioned.
ListenHttp starts an embedded Jetty server and it does not specify a hostname when creating the connector which according to Jetty documentation says that it should be binding to all available network interfaces:
"The network interface this connector binds to as an IP address or a
hostname. If null or 0.0.0.0, then bind to all interfaces."
To use HandleHttpRequest you also need to use HandleHttpResponse... you basically receive a request from a client which turns into a flow file, pass the flow file through whatever processing you want to do, and then send it to HandleHttpResponse to reply back to the client. There is a template here that shows how to use it:
https://cwiki.apache.org/confluence/download/attachments/57904847/Hello_NiFi_Web_Service.xml?version=1&modificationDate=1449369797000&api=v2
I want to record the retry attempts of a proxy service in OSB using report action.
I have created a JMS transport proxy service which would pick messages from an IN_QUEUE and routes the message to a business service which would push the message to an OUT_QUEUE and reports the status (success or failure).
However if there is an error while processing, the proxy service should retry for 5 times before getting failed. To acheive this, I have configured the routing options and gave the retry count as 5 and it works good.
All I want now is to record the retry attempts (using report action) of the proxy service. Please suggest me how to do this.
Logging the retry attempts of a business service is difficult, since it's handled out of the scope of the proxy. About the closest you can come is to set up a SLA alert to notify you when the bizref fails, but that doesn't trigger on every message - just if it detects errors during the aggregation interval.
Logging the retry attempts of the proxy is a lot easier, especially since it's a JMS proxy. Failed processing will put the message back on the queue (XA-enabled resources, you may want to enable Same Transaction For Response), and retries will increment a counter inside the JMS transport header, which the proxy can extract and decide whether to report on it or not.
Just remember that unless you set QoS to Best Effort on the publishes/reports, the publishes themselves will be rolled back if a failure happens, which is probably not what you want.
I'm using Spring jms to send jms messages to websphere mq using the target client as 1 at the destination resolver. However this causing to drop all the custom headers I've set to the jms message. When I set the target client as 0 it works perfectly bt I need to keep it at 1 for some other reason. Can somebody explain whats happening here and a possible solution. Thanks.
In MQ JMS headers are implemented as properties in an MQ RFH2 header on the message. By specifying a target client of WMQ_TARGET_DEST_MQ (1) you're instructing the MQ JMS client to strip the RFH2 header away. Which in your case means you lose your custom headers. So by setting WMQ_TARGET_DEST_MQ you're essentially opting out of this feature.
You either need to use WMQ_TARGET_DEST_JMS (0) which you know works, or find another way to pass the data in your custom headers to the receiving application.
One option if you want to continue with WMQ_TARGET_DEST_MQ is to include your custom headers in the message body as name/value pairs - you just need to make sure the receiving application can understand it.
I have a system in which different server processes are handling requests passed as JMS messages from various clients via a JMS broker.
I am trying to identify the source of the messages. Is there a way to get the IP or some identifying information about the origin ?
Clarification: I already have the client deployed by unknown users, so I'm trying to avoid changing message classes...
There is an optional JMS header mentioned in the JMS specification called JMSXUserID which which identifies the user sending a message (which the broker validates and ensures is correct to avoid spoofing) which some JMS providers support.
For example here is how to enable it in Apache ActiveMQ
I do not believe so. At least I was not able to find a way.
If you need to send a reply back to the source of the message, you can have the sender set the "JMSReplyTo" property and reply back to that destination.
Or, you could change your messaging schema slightly and embed the source information message itself. The sender would identify himself in the message and the receive could read it from there.
If you have control over the construction of the messages being sent, you can always add the IP address to the message as a property. Then you could check for the value with the getStringProperty method on Message.
If you control the code of the clients sending the messages, you could invent some property name, say "IPOfSender", and include that property on every message with Message.setStringProperty().
// client code
String myIPString = ...;
Message m = session.createTextMessage();
m.setStringProperty("IPOfSender", myIPString);
...
Its depends on your JMS Server. Some servers have Admin tools/API's that allow you to view connection details.
Using glassfish, if you look at the getJMSMessageID() of the message, you should see a string to the effect of "ID:40-192.168.0.242(f5:62:c6:58:22:6f)-52506-122885191641". It appears as though the IP is a substring of the message id.
Please note that this is what I can see under our setup, so there may be other factors at play (ie. spring), but I know that string wasn't created by us programatically.
Short answer: NO