I am performing SendMessage operation in WSO2 EI 6.4.0 using AWS SQS Connector (V1.0.7).
Sometimes Message is not posted to AWS SQS Queue, got some ERROR/WARNING Message in Log mentioned below
ERROR Code from Log:
Error_code = 101506 or Error_code = 101508
Warning Message:
[HTTPS-Sender I/O dispatcher-2] WARN {org.apache.synapse.transport.passthru.Targe
tHandler} - Connection closed by target host before receiving the response Remote Address : host/ip
So whenever failure occurs, mediation will go to fault sequence , I'm just looking for some solution like retry .
Can i add some endpoint timeout error handling inside sendMessage template code and trying to rebuild the same?
Or else inside faulty sequence shall i perform same sendMessage Operation once again ?
Kindly let me know the feasible solution..
Did you try to use a Message Store and a Message Processor to implement a Guaranteed Delivery System? You have to publish the message to a Message Store. A Message Processor can try to post it to the SQS. If it fails, it will be added to another Failover Message Store. We can add the message to the original message store after some time with the help of another Message Processor. This way, it will keep on retrying until it succeeds.
https://docs.wso2.com/display/EI640/Guaranteed+Delivery+with+Failover+Message+Store+and+Scheduled+Failover+Message+Forwarding+Processor
If this solution is too complex, you can go with your second option where you call the sendMessage Operation inside the fault Sequence.
Related
Im using WSO2 EI 6.1.1 with Message Broker, and trying to create message queue with message store and message process with an endpoint.
When I shutdown my endpoint, the message processor is deactivated and the messages stay in the queue and they are not moved to DLC.
What should I do to make it work ?
Thanks,
Faris Shomou
This is the expected behavior with message processor / message store :
A scheduled message processor will try to send the message until the
delivery is successfull (and offers you a way to implement guaranteed
delivery pattern)
A sampling message processor will send the message
in a non reliable way (it can be lost)
If you want to manage a JMS transaction and have the message to go in DLQ, use a jms inbound endpoint or jms proxy and set required parameters (transport.jms.SessionTransacted, transport.jms.SessionAcknowledgement : have a look to wso2 documentation https://docs.wso2.com/display/EI611/JMS+Transactions)
Message store / processor is used to implements Dead letter channel EIP : the jms store host the dead message and you don't want it to be moved elsewhere
I tried to follow this link , and I did it step by step for four time, for the first 3 times I used WSO2 MB as a broker, and the last time I tried Apache ActiveMQ but the problem is, when I shut down SimpleQuoteService server and send messages to the proxy via SoapUI , they accumulate in my queue and my scheduled message forwarding processor becomes inactivated after reaching max delivery attempts but WSO2-ESB documentation is sayinq :
"To test the failover scenario, shut down the JMS broker(i.e., the original message store) and send a few messages to the proxy service.
You will see that the messages are not sent to the back-end since the original message store is not available. You will also see that the messages are stored in the failover message store."
Anyone to explain?!!!
You can disable deactivating the message processor setting "max.delivery.drop" parameter to 'Enabled'. It will drop the message after max delivery attempts without deactivating the processor. See here for docs(definitions) of these parameters.
Normally when an error occurs in processing (MessageProcessor) JMS queue and goes to faultSequence and is not removed from the queue. My doubt is in some fault codes that I need to remove the message from the JMS queue even being a FAULT. Could you help me.
if you are using Message Forwarding Processor, You can not remove the message out from the Queue. It will be keep try until it send the message out successfully.
You can use Message Sampling Processor for your use case, Sample Message processor send the message only once and remove it from the queue. If you found it as a faulty attempt, you can re insert the message into the queue again based on Fault code that you got it in faultSequence.
You probably run your processor under transaction, having the following within your JMS listener config of axis2.xml:
<parameter name="transport.jms.SessionTransacted">true</parameter>
Changing this parameter to false will make your failed messages removed from the queue they were read from.
I am new to WSO2 CEP
I have created the entire flow to read the JMS message and split it using Text formatter. The problem is that when I try to push messages into the queue, it is not able to reach the the output event adaptor. I have a mysql event adaptor and configured it into my event formatter but I keep getting the below message in my log
[2014-02-13 21:20:06,347] ERROR - {ReceiverGroup} No receiver is reachable at reconnection, can't publish the events
[2014-02-13 21:20:06,352] ERROR - {AsyncDataPublisher} Reconnection failed for for tcp://localhost:7661
Can someone help me understand what is this tcp://localhost:7661 is all about
Regards
Subbu
tcp://localhost:7661 is the default port to which Thrift(WSO2 events are published). It seems a default event formatter has been created and trying to publish events to that port.
Can you check your list of event formatters and ensure that no event formatters of type WSO2Event are created. This event formatter might be automatically created if you set an exported stream to be 'pass-through' when creating the execution plan.
You can enable event tracing[1] and monitor to determine exactly upto which point the event is coming in your configured flow.
[1] http://docs.wso2.org/display/CEP300/CEP+Event+Tracer
HTH,
Lasantha
Do RabbitMQ queues have a AWS SQS-like - "message visibility timeout" ?
From the AWS SQS documentation :
"The visibility timeout clock starts ticking once Amazon SQS returns the message. During that time, the component processes and deletes the message. But what happens if the component fails before deleting the message? If your system doesn't call DeleteMessage for that message before the visibility timeout expires, the message again becomes visible to the ReceiveMessage calls placed by the components in your system and it will be received again"
Thanks!
I believe you are looking for the RabbitMQ manual acknowledgment feature. This feature allows you get messages from the queue and once you have receive them ack'ed them. If something happens in the middle of this process, the message will be available again in the queue after a certain amount of time. Also, in the meantime since you get the message until you ack it, the message is not available for other consumers to consume.
I think this is the same behavior as Message Visibility Timeout of SQS.
There aren't any message timeouts; RabbitMQ will redeliver the message only when the worker connection dies. It's fine even if processing a message takes a very, very long time.There aren't any message timeouts; RabbitMQ will redeliver the message only when the worker connection dies. It's fine even if processing a message takes a very, very long time.
I believe the answer can be found # a discussion of MQ vs SQS generally this is a considered a feature of MQ (that it can handle slow consumers) but using a destination policy of "slowConsumerStrategy" with "abortSlowConsumerStrategy" might solve your problem. A fuller explanation can be found at redhat's MQ documentation and i supposed we have to hope that rabbitMQ and AmazonMQ both support that strategy.