Unknown macro: {next_previous_link3}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

The possible exceptions relating to event publishers that may occur are as follows:

Unable to accept requests from event receivers (WSO2 event publisher)

The Analytics profiles of WSO2 EI, WSO2 API-M, and WSO2 IS have publishers of the wso2event type configured in them. The information given below also applies if this exception occurs in any of these profiles.

Sample Error log
org.wso2.carbon.databridge.agent.exception.EventQueueFullException: Cannot send events because the event queue is full
at org.wso2.carbon.databridge.agent.endpoint.DataEndpointGroup$EventQueue.tryPut(DataEndpointGroup.java:124)
at org.wso2.carbon.databridge.agent.endpoint.DataEndpointGroup$EventQueue.access$100(DataEndpointGroup.java:104)
at org.wso2.carbon.databridge.agent.endpoint.DataEndpointGroup.tryResendEvents(DataEndpointGroup.java:295)
at org.wso2.carbon.databridge.agent.endpoint.DataEndpoint$EventPublisher.handleFailedEvents(DataEndpoint.java:271)
at org.wso2.carbon.databridge.agent.endpoint.DataEndpoint$EventPublisher.run(DataEndpoint.java:245)
at java.lang.Thread.run(Thread.java:745)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.lmax.disruptor.InsufficientCapacityException
OccurrenceThis occurs when events published by WSO2 DAS via a publisher of the wso2event type do not reach the endpoint.
Possible reasons
  • A failure in the network connection.
  • Unavailability of the receiver node to which the events are published (e.g., if it is unreachable, shut down etc.)
  • The receiver not being responsive (e.g., due to an error is the connection, due to the receiver queue being full etc.)
  • The internal queue of the receiver node to which the events are published being full.
Recommended action
  • Increase the event queue size at databridge level. This is done by editing the QueueSize parameter in the <DAS_HOME>/repository/conf/data-bridge/data-agent-config.xml file. The result of doing this also depends on the other parameters configured in the data-agent-config.xml file. Therefore, for more details, see Performance Tuning - Publishing Events.
  • Check the connectivity health of the connection with the receiver endpoint.
  • Check the status of the receiver, and ensure that it is able to accept messages.
  • Use a blocking publisher of the wso2event type instead of a non-blocking publisher. If the disruptor queue is full at a given time, a blocking publisher waits until there is space in the queue to insert the event instead of returning the method call to publish the event and throwing the EventQueueFull exception. The following diagrams illustrate the difference between blocking and non-blocking publishers in their approach to handle events to be published when the disruptor queue is full.

    This can cause back pressure on the publisher. As a result, the publisher itself can be blocked from publishing events.


  • No labels