I am trying to establish a tcp socket connection to a spring integraton gateway. The byte arrat messages are rather large and I have setup the ByteArrayLengthHeaderSerializer to handle it by modding the property maxMessageSize to handle the messages. However, the messages are instead being handled in chunks, the first only 28 bytes in size before the service-activator is called. I know that there is an Aggregator that could be used but I was thinking I might have setup the integration components incorrectly. I am using the basic spring jars 3.0.5 and the integration 2.0.2 and the integrationContext.xml is here:
Does anyone have any suggestions
Thanks
The source had a mangled header value which gave a false reading as to the size of the message coming. Once the header was fixed there was no problem.
Related
I am not very familiair with Spring Integration (I am taking the project over from a colleague) but I am encountering the following problem that probably is being caused by the use of the ByteArrayCrLfSerializer;
The message that is ultimately send through the TCP connection ends with an additional '\r\n'.
According to the documentation, we need to use the ByteArrayRawSerializer.
My question is;
How can we overrule/overwrite/set the ByteArrayRawSerializer to being used instead of the ByteArrayCrLfSerializer?
The message to be serialized one-on-one without additional characters.
Im using Http Client Processor app in one of my stream which is a standard app of SCDF.The puspose of this app is to make http calls against provided URL with a message payload. I tried to enable the retry mechanism of this app by keeping the boolean httpclient.retry.enabled to 'true'.
But when I do that it try to repost the message against the http end point even if the first attempt is succecssfull. It looks like it is working with the concept of 'write at least once'. The problem with this approach is, it creates duplicates in the target system.
Is there a way we can configure it for 'write just once if the call is successful else, retry'. If not can we expect a fix from Spring ?
The Http Client Processor is no longer supported. I recommend upgrading to HttpRequestProcessor. This uses the common retry mechanism included in the messaging binder. The behavior is as you describe, the request will be retried only if the consumer fails to acknowledge the message. With at least once guarantees, you still have the potential for duplicates.
My goal is to define some API using REST arch style and spring boot in order to store messages to activemq message broker. I would like to have REST on top of message broker to have possibility to restrict message format. Actually the main goal is to allow only messages which contains all nessessary fields inside message payload.
Could you please suggest if it is rigth way to go and if there are any alternative ways to achive the goal?
Yes. This is a REST-to-Messaging Proxy design and can work just fine for the use case you described.
Alternatively, you could do the message inspection in the broker, but since this inspection sounds logic-related, it is best suited for something running outside the broker.
I realize there is a method to set on MQConnectionFactory to attempt to reconnect if the connection of a consumer or producer is broken. However, I'm wondering if one can do something similar for an application that is starting up and setting up consumers and producers. The code I have right now will not recover if the server is down when my client application comes up.
Is there a common/recommended practice here?
My recommendation would simply be to use the tools that are provided in the Java language itself. For example, you could write a loop with exception handling to retry the initial connection or JNDI lookup a configurable number of times. It's hard to provide more specific recommendations when you haven't provided any client code of your own.
I am connecting to TCP socket using spring integration. I send 2 different messages on an outbound gateway which returns same outputs i.e. header as well as payload.
Now I want to process reply messages differently and then aggregate into a single message which can then be processed by main service class.
I tried various techniques but nothing worked.
Is it feasible to do so? If yes, kindly help me out.
You need something to correlate the messages, maybe a header (e.g. the standard correlation id).
Use a header-enricher to set the correlation id header on each outbound message. Send the reply messages to an <aggregator /> with a simple release strategy (release-strategy-expression="size() == 2"). When the second reply is received, a message with a payload (collection of the 2 payloads) will be released.