I am using wso2 message broker as a message brokering system in my project. Before using wso2 message broker, I want to explore exceptional cases related to wso2 message broker queue/topic -
How many messages queue/topic can store if consumer is down and publisher is continuously sending message to queue/topic ?
What will happen if queue/topic is not available and publisher is trying to post message in queue/topic?
What is the maximum size of message queue/topic can store ? Is it configurable ?
What is the JSON message format of wso2 message broker?
Can consumer sends response to publisher after getting message from queue/topic ? If yes, How ?
What is the duration of queue/topic session timeout ? Is it configurable ?
Please find answers below.
How many messages queue/topic can store if consumer is down and publisher is continuously sending message to queue/topic ?
This depends on how much space is allocated for MB server. The messages are persisted into the DB.
What will happen if queue/topic is not available and publisher is
trying to post message in queue/topic?
Message Broker will not accept the messages. Will simply drop them.
What is the maximum size of message queue/topic can store ? Is it
configurable ?
There is no defined limit. But MB is tested with upto 10MB messages. But the performance degrades drastically as the message size grows.
What is the JSON message format of wso2 message broker?
There is no such thing.
Can consumer sends response to publisher after getting message from
queue/topic ? If yes, How ?
This is not actually supported by AMQP. In AMQP the publisher and the subscriber is decoupled. SO through WSO2 MB you cannot get this done.
What is the duration of queue/topic session timeout ? Is it
configurable ?
This can be set from the client side when connection is made.
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.
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.
exist in WSO2-ESB a mechanism to save the messages in a persistent manner and handle the send retry in the event of a serious error (eg server crash) ?
Thank you
Gordon
You just have to use a Message Store plugged on a JMS Broker (a "JMS Message Store" that will use a JMS Queue) and a Message Processor that will dequeue messages from the store.
"store" mediator will be used inside a mediation to store a Message in the store
See https://docs.wso2.org/display/ESB481/Message+Stores
and https://docs.wso2.org/display/ESB481/Message+Processors
i have wrote a Text Message Sender Program via JMS with C++ following.
tibems_status status = TIBEMS_OK;
status = tibemsMsgProducer_SendToDestination(
m_tProducer,
m_tDestination,
m_tMsg );
Suppose status == 0, this means only that Function has worked succesfull. It doesn't mean that my Text Message was sent succesfull
How can I ensure that my Message was sent succesfull? Should I get a ID or Acknowledge from JMS Queue back?
It depends on the Message Delivery Mode.
When a PERSISTENT message is sent, the tibemsMsgProducer_SendToDestination call will wait for the EMS server to reply with a confirmation.
When a NON_PERSISTENT message is sent, the tibemsMsgProducer_SendToDestination call may or may not wait for a confirmation depending on if authorization is enabled and the npsend_check_mode setting. See the EMS docs (linked above) for specific details.
Lastly, when a RELIABLE_DELIVERY message is sent, the tibemsMsgProducer_SendToDestination call does not wait for a confirmation and will only fail if the connection to the EMS server is lost.
However, even in the situations where a confirmation is sent, this is only confirmation that the EMS server has received the message. It does not confirm that the message was received and processed by the message consumer. EMS Monitoring Messages can be used to determine if the message was acknowledged by the consumer.
The message monitoring topics are in the form $sys.monitor.<D>.<E>.<destination>, where <D> matches Q|q|T|t, <E> matches s|r|a|p|\* and <destination> is the name of the destination. For instance to monitor for message acknowledgment for the queue named beterman, your program would subscribe to $sys.monitor.q.a.beterman (or $sys.monitor.Q.a.beterman if you want a copy of the message that was acknowledged).
The monitoring messages contain many properties, including the msg_id, source_name and target_name. You can use that information to correlate it back to the message you sent.
Otherwise, the simpler option is to use a tibemsMsgRequestor instead of a tibemsMsgProducer. tibemsMsgRequestor_Request will send the message and wait for a reply from the recipient. In this case you are best to use RELIABLE_DELIVERY and NO_ACKNOWLEDGE to remove all the confirmation and acknowledgement messages between the producer and the EMS server and the EMS server and the consumer.
However, if you do go down the tibemsMsgRequestor route, then you may also want to consider simply using a HTTP request instead, with a load balancer in place of the EMS server. Architecturally there isn't much difference between the two options (EMS uses persistent TCP connections, HTTP doesn't)
Producer -> EMS Server -> ConsumerA
-> ConsumerB
Client -> Load Balancer -> ServerA
-> ServerB
But with HTTP you have clear semantics for each of the methods. GET is safe (does not change state), PUT and DELETE are idempotent (multiple identical requests should have the same effect as a single request), and POST is non-idempotent (it causes a change in server state each time it is performed), etc. You also have well defined status codes. If you're using tibemsMsgRequestor you'll need to create bespoke semantics and response status, which will require extra effort to create, maintain and to train the other developers in your team on.
Also, it far easier to find developers with HTTP skills than EMS skills and it's far easier to find information HTTP that EMS, so the tibemsMsgRequestor option will make recruiting more difficult and problem solving issues more difficult.
Because of this HTTP is a better option IMO, for request-reply or for when you want to ensure that that the message sent was processed successfully.