incubator-nuvem-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <>
Subject Re: GSOC 2012 - Message Queue component for Nuvem
Date Sun, 29 Jul 2012 15:37:56 GMT
Any update?


- Jean-Sebastien

On Mon, Jul 16, 2012 at 1:35 AM, Jean-Sebastien Delfino <> wrote:

> On Fri, Jul 13, 2012 at 12:25 AM, Dulini Atapattu <>wrote:
>> Hi Jean and all,
>> The design for the api of message queue component for nuvem is as follows
>> (The MessageQueueService interface):
>> *public QueueMessageHandle sendMessage(QueueMessage queueMessage) throws
>> MessageQueueServiceException;*
>> (Sends the queueMessage and returns a handle to the sent message)
>> *public List<QueueMessage> receiveMessage(int numMessages) throws
>> MessageQueueServiceException;*
>> (Receives the number of messages specified by numMessages from the queue
>> service and returns a list of queue messages)
>> *public boolean deleteMessage(QueueMessage queueMessage) throws
>> MessageQueueServiceException;*
>> (Deletes the message specified by the queueMessage and returns true if
>> deletion is successful)
>> The *QueueMessage* class represents a message sent by the user to a queue,
>> and has attribtues: id and messageBody, that stores the id of a message
>> and
>> message body text of the message. User may set the messageBody in a
>> QueueMessage object and pass it to the sendMessage method, then the method
>> return a QueueMessageHandle object, with the id returned to the message
>> and
>> message body. When receiving a messages, a user has to pass the number of
>> messages he/ she needs to receive and pass it to the receiveMessage
>> method.
>> The receiveMessage method will then return a list of QueueMessage objects,
>> each representing a message in the queue. The user may delete a message by
>> passing a required QueueMessage object received by receiveMessage method,
>> to the deleteMessage method and the method will return true, if deletion
>> is
>> successful.
>> This interface is implemented to Amazon and GAE platforms using AmazonSQS
>> and TaskQueue  (PullQueue) respectively. I used the AWS SDK for Java
>> related to AmazonSQS [16] to implement for Amazon platform and TaskQueue
>> REST API [17] to to implement for GAE platform. The Task Queue REST API
>> allows consumption of messages from task queue, for the consumers that may
>> be hosted even outside GAE.
>> The user may call the required constructor from the required
>> implementation
>> and the rest of the user code may remain unchanged.
>> *The Configuration and running of test cases is as follows:*
>>    - Add the AWS access key and secret key of the user to the
>>    nuvem-amazon/source/test/resources/ file.
>>    - Remove the following line in nuvem-amazon/pom.xml file:
>>         <exclude>**/</exclude>
>>    - Create a queue named "MyQueue" in the Amazon cluster.
>>    - Then run the project using mvn clean install
>> *Implementation to GAE:*
>> I am now on the testing stage of GAE implementation and I have few
>> problems
>> related to configuring to GAE Taskqueue as I am using the REST API in the
>> implementation.
>> I would like to receive any comments regarding the work.
>> Thanks
>> [16] -
>> [17] -
> Thanks, that helps!
> I've reviewed your patch and committed it under SVN revision r1361932.
> Here are a few review comments, suggestions and questions:
> - I'd suggest to keep the package names lowercase and perhaps shorten
> 'messageQueueService' a little. How about just 'queue'?
> - Also perhaps shorten 'QueueMessage' to 'Message', as there's nothing
> that really ties your message to a queue, and if you just want to indicate
> that this type of message is for use with queues, your package name already
> indicates that.
> - I'm not sure that you need the setter methods on QueueMessage, as your
> constructor already allows to initialize all its properties. It may be
> simpler to just make it immutable.
> - I don't think that the following error handling code:
> } catch(Exception e) {
>     throw new MessageQueueServiceException(e);
> }
> actually helps the caller. Why is wrapping all exceptions in a
> MessageQueueServiceException better than just letting the original
> exceptions go through?
> - It seems that the only interesting property in QueueMessageHandle is the
> message ID returned by the queuing service after you send a message. What
> would you think about changing sendMessage to simply return that message ID
> instead of a QueueMessageHandle wrapper object (and then just get rid of
> that QueueMessageHandle class altogether)?
> - deleteMessage only needs a message ID (which you currently get from the
> message passed in as a parameter). How about just passing the message ID
> directly to deleteMessage instead of requiring the caller to pass the whole
> message (which forces him to keep it around in memory until he's ready to
> call deleteMessage)?
> - I'd suggest to add a few real unit tests. I mean tests that mockup the
> system dependencies (on EC2, SQS etc) to exercise your code without
> requiring an actual EC2 instance and SQS queue. That way, others in the
> project can verify that your code does what you intended to do when they
> build, without having to set up an EC2 account etc.
> - Did you manage to implement the same interfaces on GAE? When I initially
> looked at your interfaces I thought that they looked very close to the SQS
> interfaces and was wondering how you'd implement them on GAE... Did you run
> into any issues there?
> Thanks!
> - Jean-Sebastien

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message