I am using WSO2 CEP 4.2.0 and have created MQTT input event adapter. I have also created the receiver which will receive the data from a external topic and then using streams, I am adding some logics and then same message will be published using publishers to another external topic.
Now, When I restart the application, I get below two messages:
INFO {org.wso2.carbon.event.input.adapter.core.internal.InputAdapterRuntime} - Connecting receiver mqttreceiver_test
INFO {org.wso2.carbon.event.input.adapter.mqtt.internal.util.MQTTAdapterListener} - MQTT Connection successful
And then When I am publishing the message from external mqtt client, I can see that message arrives the event receiver and after stream processing, the message goes to output event publisher.
But after approx 5 mins, the messages are not received any more in the event receiver. I do not get any error message also in logs but what I could sense is may be the input adapter is not listening any more.
Any suggestions or any guidance will help.
Thanks
Few things I could suggest to debug this issue:
Perhaps the flow is broken so that the event does not reach the
output event publisher? You could use logger event publisher [1] and log
the stream that is generated by the MQTT input event adapter.
Enable debug logs for package
org.wso2.carbon.event.input.adapter.mqtt.internal.util so that you
will see a log when the MQTTAdapterListener receives a message (See
[2] ). You can follow [3] to enable debug logs.
When the issue
happens, take a thread dump and see whether the MQTTAdapterListener
thread is running.
Hope these will help you to narrow down the issue.
[1] https://docs.wso2.com/display/CEP420/Logger+Event+Publisher
[2] https://github.com/wso2/carbon-analytics-common/blob/v5.1.3/components/event-receiver/event-input-adapters/org.wso2.carbon.event.input.adapter.mqtt/src/main/java/org/wso2/carbon/event/input/adapter/mqtt/internal/util/MQTTAdapterListener.java#L150
[3] https://docs.wso2.com/display/CEP420/Logging
Related
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.
Is it possible to ensure that a message was successfully delivered to an Event Hub when sending it with the log-to-eventhub policy in API Management?
Edit: In our solution we cannot allow any request to proceed if a message was not delivered to the Event Hub. As far as I can tell the log-to-eventhub policy doesn't check for this.
Welcome to Stackoveflow!
Note: Once the data has been passed to an Event Hub, it is persisted and will wait for Event Hub consumers to process it. The Event Hub does not care how it is processed; it just cares about making sure the message will be successfully delivered.
For more details, refer “Why send to an Azure Event Hub?”.
Hope this helps.
Event Hubs is built on top of Service Bus. According to the Service Bus documentation,
Using any of the supported Service Bus API clients, send operations into Service Bus are always explicitly settled, meaning that the API operation waits for an acceptance result from Service Bus to arrive, and then completes the send operation.
If the message is rejected by Service Bus, the rejection contains an error indicator and text with a "tracking-id" inside of it. The rejection also includes information about whether the operation can be retried with any expectation of success. In the client, this information is turned into an exception and raised to the caller of the send operation. If the message has been accepted, the operation silently completes.
When using the AMQP protocol, which is the exclusive protocol for the .NET Standard client and the Java client and which is an option for the .NET Framework client, message transfers and settlements are pipelined and completely asynchronous, and it is recommended that you use the asynchronous programming model API variants.
A sender can put several messages on the wire in rapid succession without having to wait for each message to be acknowledged, as would otherwise be the case with the SBMP protocol or with HTTP 1.1. Those asynchronous send operations complete as the respective messages are accepted and stored, on partitioned entities or when send operation to different entities overlap. The completions might also occur out of the original send order.
I think this means the SDK is getting a receipt for each message.
This theory is further aided by the RetryPolicy Class used in the ClientEntity.RetryPolicy Property of the EventHubSender Class.
In the API Management section on logging-to-eventhub, there is also a section on retry intervals. Below that are sections on modifying the return response or taking action on certain status codes.
Once the status codes of a failed logging attempt are known, you can modify the policies to take action on failed logging attempts.
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.
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