Hi All, >From the above highlighted points, except receiving messages asynchronously i prefer to use AmazonSQS without JMS.
Your valuable suggestions are highly appreciated. Thanks, Biruntha Associate Software Engineer WSO2 Email : [email protected] Linkedin : https://lk.linkedin.com/in/biruntha Mobile : +94773718986 On Thu, Sep 29, 2016 at 9:33 PM, Biruntha Gnaneswaran <[email protected]> wrote: > Hi All, > > According to the code review comments, I have compared “Using AmazonSQS > with JMS” and “Using AmazonSQS without JMS” for AmazonSQS inbound by > running sample client and listed those results as below, > > Using AmazonSQS with JMS > > For this, we need AWS SDK for Java and the Amazon SQS Java Messaging > Library that lets you create JMS connections and sessions, as well as > producers and consumers that send and receive messages to and from Amazon > SQS queue. This Amazon SQS Java Messaging Library supports the JMS 1.1 > specification. > > > - > > It supports receiving messages synchronously or asynchronously. To > receive messages synchronously, call the receive method on the consumer > with a timeout period. To receive messages asynchronously, instead of > explicitly calling the receive method on the consumer, the message listener > of the consumer is used to consume the message and it will wait until the > user defined time and return. > - > > It also supports different acknowledge modes. When a message is > acknowledged, it will be deleted from the queue as well. > > > 1. Client Acknowledge Mode - In this mode, client needs to explicitly > acknowledge the messages after they are processed. When a message is > acknowledged, then all the messages received prior to this message are > implicitly acknowledged as well. (This acknowledge mode can’t be used > in AmazonSQS inbound. Because after the message consumption from queue, we > need to individually acknowledge the messages) > 2. Unordered Acknowledge Mode - In this mode, received messages must > be individually and explicitly acknowledged by the client, regardless of > their reception order. > > > - > > It supports for the message selectors that allow you to filter the > messages that a message consumer will receive. > - > > Only one message will be received per poll from the queue. To get the > all message, need to poll the queue multiple times. > > > Using AmazonSQS without JMS > > - > > It only supports receiving messages synchronously. > - > > Instead of above acknowledge modes, the messages have to deleted using > deleteMessage() > method from the queue after it has been processed. > - > > Instead of message selectors, we can use message attributes to filter > the messages. > - > > One/more message/s will be received per poll to the queue. > > > > Thanks, > > Biruntha > > Associate Software Engineer > WSO2 > Email : [email protected] > Linkedin : https://lk.linkedin.com/in/biruntha > Mobile : +94773718986 > > On Tue, Sep 6, 2016 at 1:56 PM, Malaka Silva <[email protected]> wrote: > >> Hi Biruntha >> >> I think >> ReceiveMessageWaitTimeSeconds >> can be given as a parameter to inbound ep and users can decide with >> option to use. >> >> On Tue, Sep 6, 2016 at 1:46 PM, Biruntha Gnaneswaran <[email protected]> >> wrote: >> >>> Hi All, >>> >>> >>> For message retrieval from the Amazon SQS queue will depend on the short >>> polling or long polling. For this, we can set a time limit to wait when >>> polling queues for messages. Short polling is when we make a request to >>> receive messages without setting the ReceiveMessageWaitTimeSeconds >>> property for the queue (that means 0 sec). Setting the >>> ReceiveMessageWaitTimeSeconds property to up to 20 seconds (20 seconds is >>> the maximum wait time) will cause the call to wait up to 20 seconds for a >>> message to appear on the queue before returning. If there is a message on >>> the queue, then the call will return immediately with the message this may >>> be all of the messages (up to maximum number that is 10), or a subset of >>> the messages. SQS short polling returns immediately even if the queue >>> being polled is empty, SQS long polling doesn’t return a response until a >>> message arrives in the queue, or the long poll times out. So, the advantage >>> of using long polling is to eliminate a large number of empty polls and >>> false empty responses. >>> >>> So, To consume messages from the Amazon SQS inbound Endpoint Long >>> polling is better than short polling. >>> >>> Thanks, >>> >>> Biruntha >>> >>> Associate Software Engineer >>> WSO2 >>> Email : [email protected] >>> Linkedin : https://lk.linkedin.com/in/biruntha >>> Mobile : +94773718986 >>> >>> On Tue, Sep 6, 2016 at 11:01 AM, Biruntha Gnaneswaran <[email protected] >>> > wrote: >>> >>>> Hi All, >>>> >>>> I have herewith attached [1] to my milestone plan for the Amazon SQS >>>> Inbound Endpoint. >>>> >>>> Please let me know, if there's anything else I missed. >>>> >>>> [1] - https://docs.google.com/spreadsheets/d/1Z9kTl8CcWx24fePd5CZH >>>> iH4A8eS6F5g_jQGRW7PnZCY/edit#gid=0 >>>> >>>> >>>> Thanks, >>>> >>>> Biruntha >>>> >>>> Associate Software Engineer >>>> WSO2 >>>> Email : [email protected] >>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>> Mobile : +94773718986 >>>> >>>> On Thu, Sep 1, 2016 at 10:57 AM, Biruntha Gnaneswaran < >>>> [email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> Architecture diagram : >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Biruntha >>>>> >>>>> Associate Software Engineer >>>>> WSO2 >>>>> Email : [email protected] >>>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>>> Mobile : +94773718986 >>>>> >>>>> On Thu, Sep 1, 2016 at 10:31 AM, Biruntha Gnaneswaran < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I have planned to implement Amazon SQS inbound endpoint to listen and >>>>>> consume messages from Amazon SQS. The behaviour of this inbound endpoint >>>>>> is >>>>>> polling. >>>>>> >>>>>> Architecture diagram - [1]. >>>>>> >>>>>> Amazon Simple Queue Service (Amazon SQS) offers reliable and scalable >>>>>> hosted queues for storing messages. It is a distributed queue system that >>>>>> enables quickly and reliably queue messages. >>>>>> >>>>>> *Characteristic of Amazon SQS queue :* >>>>>> >>>>>> - >>>>>> >>>>>> The messages will be available up to maximum 14 days in the >>>>>> queue, provided that no delete action is performed. >>>>>> - >>>>>> >>>>>> The order of the messages will not be guaranteed. >>>>>> - >>>>>> >>>>>> The messages are highly available as the SQS will keep the >>>>>> redundant messages across the multiple Amazon SQS servers. >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> The message retrievable will depend on the short polling or long >>>>>> polling. >>>>>> - >>>>>> >>>>>> *Short Polling: *In the short polling, the Amazon SQS will >>>>>> sample subset of servers from the available SQS servers to >>>>>> retrieve the >>>>>> messages. Due to this, to get all the messages we need to poll >>>>>> multiple >>>>>> times. This technique will give empty responses to the receivers >>>>>> even >>>>>> though the queue doesn’t contain any messages. >>>>>> - >>>>>> >>>>>> *Long Polling:* In the long polling, the Amazon SQS will poll >>>>>> all the servers to get the messages. So, with less number of calls >>>>>> to make >>>>>> to SQS to get the messages. In this mechanism, the queue will not >>>>>> send any >>>>>> response back to the receiver if there are no messages available >>>>>> in the >>>>>> queue. >>>>>> >>>>>> >>>>>> - >>>>>> >>>>>> Amazon SQS won’t delete the messages after consuming it. The >>>>>> consumer has to perform delete message operation after consuming it by >>>>>> setting “*visibility timeout*“*, *which is a time period during >>>>>> which the SQS hide the messages to consume. >>>>>> >>>>>> >>>>>> Your comments and suggestions are highly appreciated. >>>>>> [1] - >>>>>> *https://docs.google.com/document/d/1tuRUZUDQyonEBIHyocxTIkZu4nERD99TY_pyw35oavs/edit* >>>>>> <https://docs.google.com/document/d/1tuRUZUDQyonEBIHyocxTIkZu4nERD99TY_pyw35oavs/edit> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Biruntha >>>>>> >>>>>> Associate Software Engineer >>>>>> WSO2 >>>>>> Email : [email protected] >>>>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>>>> Mobile : +94773718986 >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Technical Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> https://wso2.com/signature >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> https://store.wso2.com/store/ >> >> Don't make Trees rare, we should keep them with care >> > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
