[jira] Commented: (NUVEM-7) Store application updated to use the XMPP feature
[ https://issues.apache.org/jira/browse/NUVEM-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12974836#action_12974836 ] Jean-Sebastien Delfino commented on NUVEM-7: Starting to review this patch. Will post progress and comments here. Store application updated to use the XMPP feature - Key: NUVEM-7 URL: https://issues.apache.org/jira/browse/NUVEM-7 Project: Nuvem Issue Type: Improvement Reporter: John Pradeep Attachments: nuvem-cloud-api.patch, store-appengine-webapp.patch, store-assets.patch The store sample application is updated to use the Nuvem XMPP feature. Also, i have made few domain classes in Nuvem API to implement serializable. I have modified the store-asset module to implement the shipment service feature... we can seperate out this into store-shipment module if necessary but before that we should have the common domain model across all modules to be separated out to avoid cross-dependencies. Please find the attached patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
XMPP chat component and REST
Hi all, Now that we have a first implementation of an XMPP API and component implementation, how about building even simpler components on top of that, with a REST interface for example? Here are some initial thoughts and usage scenarios: - A sender component, configured with two 'jid' and 'password' properties. To logon as j...@doe.com configure the 'jid' property. To send a message to j...@doe.com, POST the message string to /component-uri/j...@doe.com. - A receiver service component, configured with two 'jid' and 'password' properties and a 'listener' reference. To logon as j...@doe.com configure the 'jid' property. The component receives messages sent to joe and POSTs them to the component wired to 'listener'. - Or a sender-receiver service component that does both? - And perhaps a logger component that logs messages and returns them on a GET? I did something like that before in Tuscany C++ (just a sender and a sender-receiver) and that seemed to work. It shouldn't be too difficult to write Java or Python implementations of a similar REST scheme here, on top of what John has already contributed. Thoughts? [1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/components/chat/ -- Jean-Sebastien
Re: XMPP chat component and REST
On 02/10/2011 12:11 AM, Luciano Resende wrote: On Wed, Feb 9, 2011 at 1:06 PM, john pradeepyehohan...@gmail.com wrote: Hi Jean, That's a nice idea... I Just started today to see how we can use apache vysper for XMPP in cloud platforms which doesn't provide pre-defined APIs for XMPP as provided by GAE. I understand that vysper can run as a standalone server and also it can be embedded into the application, would it be a good idea to provide Nuvem APIs to start the embedded XMPP server in a dedicated thread and APIs to register users with the XMPP server? I am trying out vysper now, any suggestions would be helpful. Regards, John I have something that start a Vysper server, let me see if I can post it to my sendbox so you can play with it. Sounds good! I also had some code to start Vysper there [1] (used to unit test Tuscany C++ chat components), if that helps. [1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/components/chat/test/TestVysperServer.java -- Jean-Sebastien
Re: store app on EC2
On Mon, Feb 28, 2011 at 2:58 PM, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Feb 28, 2011 at 2:32 PM, john pradeep yehohan...@gmail.com wrote: Hi, Has Anyone deployed the sample app on EC2? Was Just trying to configure an EC2 instance, but wanted to know if anyone did that already? so that I can use the same settings to remain consistent with everyone. Regards, John We did a demo at JavaOne last year, and we used GAE, Amazon, and private cloud. But I'd defer to Sebastien to provide more details on the Amazon settings as we handled most of the details on that part. I was using Tuscany C++ on EC2 and there was nothing special to it, just an Ubuntu VM loaded with the Tuscany runtime. Tuscany C++ provides a few scripts [1] to checkout and build the C++ runtime on a fresh ubuntu VM. Similar story for Tuscany Java: pick an OS VM, install a JDK, download and install Tuscany, or checkout the source and build it. [1] http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/ubuntu/ -- Jean-Sebastien
Re: nuvem restructuring
On Sat, May 7, 2011 at 5:31 PM, john pradeep yehohan...@gmail.com wrote: I have restructured the modules, I still haven't moved the python modules though. Tried to configure hudson for nuvem but looks like I don't have enough privilege to create new hudson jobs, waiting for Luciano to give me the access. Regards, John On Sat, May 7, 2011 at 7:54 PM, john pradeep yehohan...@gmail.com wrote: Hi All, I created a branch branches/before_restructure to backup existing nuvem structure so that I can start re-structuring the code base in trunk and later configure hudson for each project. The structure will appear as we decided sometime back, but with few additions for python projects as Jean started working on python support. Each feature will exist as a defined package in every platform specific project. Jean, Are you ok with the naming convention for python projects? nuvem-api nuvem-commons nuvem-google nuvem-azure nuvem-ibm nuvem-standalone nuvem-python-google nuvem-python-standalone nuvem-samples store-commons store-ibm store-google store-standalone Regards, John Hi John, The new structure for Java projects looks good to me. With respect to the Java vs Python modules, I find it strange to name the Python projects *-python-* and not name all the Java projects *-java-*. On the other hand, it'd be nice to keep the names simple and not pollute them all with *-java-*, like you've done here. If you're a Java user or a Python user, I think you want to pick a set of modules once for all and don't need their naming convention to remind you which programming language you're using :) In the long term and if the Python work picks up some steam, I'd suggest different top level directories for Java and Python, like this: nuvem/java/trunk/nuvem-api nuvem/java/trunk/nuvem-commons ... nuvem/java/branches/ ... nuvem/python/trunk/nuvem-api nuvem/python/trunk/nuvem-commons ... nuvem/python/branches/ ... For the shorter term, nuvem-parallel is the only Python module and doesn't conflict with the other modules, so how about simply keeping it as is at the same level as the others? I'm happy to revisit that when there's more modules. What do you guys think? -- Jean-Sebastien
Re: SSL error for apache Vysper
On Mon, Apr 4, 2011 at 3:00 PM, john pradeep yehohan...@gmail.com wrote: Hi, I was trying to write an SSL XMPP connector to connect to the apache vysper server in a secure way, but couldn't quite get through :( I used the certificate bogus_mina_tls.cert available under nuvem-cloud-standalone-xmpp, this allows the vysper server to start properly but I am not able to import this same certificate into my keystore, trying to do so flags an error saying - Input not an X.509 certificate Alternatively, I generated my own certificated in X.509 format which imports smoothly into my keystore but the vysper server fails to start with this new certificate I generated!! vysper throws an error - Invalid keystore format Jean, I don't know if I am missing something trivial, but I wanted to know if you Identified any similar issue while using vysper in tuscany? Regards, John Sorry for the long delay, I missed that message... I also ran into keystore issues with Vysper last year as I was trying different JDKs [1]. My error message was different than yours, but this may be a JDK issue. IIRC at the time I had found that different JDKs had different keystore formats... but again this was a year ago so I can't remember the details. Which JDK are you using? [1] http://markmail.org/thread/mw4rgrv37sylblqd -- Jean-Sebastien
Re: SCA contribution/composite
Hi John, Your proposal looks good to me, with a few comments: IIRC contributions don't have a namespace. I'm not sure how to reuse feature composites, as you'll need to configure their components for specific apps, hosts, ip addresses, user ids etc. They're useful though, as examples, templates or palettes that the developer can review before creating his own. But then their namespaces don't matter. Thoughts? -- Jean-Sebastien Sent from my iPhone On May 31, 2011, at 3:31 PM, john pradeep yehohan...@gmail.com wrote: Hi, I am trying to organize the composite and contribution files for all modules and thought of the below approach. 1. Each SCA contribution corresponding to a cloud platform will have a specific namespace *Example:* contribution xmlns= http://docs.oasis-open.org/ns/opencsa/sca/200912; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.1; xmlns:xmpp=*http://nuvemstandalone*; 2. we will have a composite for each feature with the same namespace as it is defined in its sca contribution but the name of the composite itself will indicate the feature * Example:*composite xmlns= http://docs.oasis-open.org/ns/opencsa/sca/200912; xmlns:tuscany=http://tuscany.apache.org/xmlns/sca/1.1; *targetNamespace=http://nuvemstandalone; name=xmpp* 4. The component/service names within the composites will be Identified with the same names across all SCA contributions to keep it consistent. 5. Since the component names are maintained same across all platforms, the client will always refer to the same component/service name but will import the right namespace to choose the contribution (google, standalone etc) I haven't tried to import a composite just by its name space in tuscany yet, but i assume it should be possible? Please let me know your thoughts. Regards, John
Re: GSOC 2012 - Message Queue component for Nuvem
Hi Dulini, Sorry for the late response, I was really busy the last few days. At first glance your design looks good to me. I'll post some more thoughts on the project over the weekend. - Jean-Sebastien On Thu, May 24, 2012 at 10:27 PM, Sagara Gunathunga sagara.gunathu...@gmail.com wrote: Sounds good to me. Thanks ! On Fri, May 25, 2012 at 12:24 AM, Dulini Atapattu dulin...@gmail.com wrote: Hi Jean and all, I re-designed the message queue api according to Sagara's comments which was helpful. According to the comments it was reallized that the api should have seperate services representing different tasks, where a given queue service may not support all the services in the api we are providing. According to the information that I read so far, AmazonSQS has the api that provides the most number of services. Thus our api should have separate services to each of those services in AmazonSQS, where then services provided by each other queue service (MemcacheQ etc.) becomes a subset of those services that we may provide with our api. Also this such api provides flexibility to add more services to the api as required and as different queue services may introduce more services or we need our api to be adopted to any other queue service. Thus I would propose the api as follows: *Queue related services:* *createQueue - create a new queue* *deleteQueue - delete the specified queue **listAllQueues - list all the queues* clearQueue - clear the contents of a specified queue clearAllQueues - clear the contents of all the queues *SetQueueAttributes - set the queue related properties* *GetQueueAttributes - get the queue related properties* *GetQueueUrl - get the queue URL* *SetQueuePermission - set queue related permissions* *RevokeQueuePermission - get existing queue related permissions* *Message related services in queues* *SendMessage* - add a message to a specified queue *SendMessages* - add multiple messages to a specified queue *ReceiveMessage - receive a message/ s from a specified queue* *DeleteMessage - delete a message in a queue* *DeleteMessages* - *delete multiple messages in a queue* *ChangeMessageVisibility* - change visibility timeout for the previous received message *ChangeMessagesVisibility* - change visibility timeout for the previous received messages Exceptions will be thrown in our implementations of the above api for different queue services, where the services are not supported according to the queue service. Also I will be considering on implementing the above api for, - GAE: MemchacheQ - AmazonSQS - ActiveMQ (according to my readings so far, ActiveMQ is the mostly being used and more powerful upto now, thus I suppose implementing to ActiveMQ would be much useful [1], [2]) **Also regarding the licenses, MemcacheQ [3] has the New BSD License which is compliant with Apache [4]. I also will be using the AWS Free Usage Tier [5] which provides many services free for one year and where SQS will be free indefinitely, which will be helpful in testing api with Amazon plateform (According to Pasindu Gunarathne). I would like to know the comments about the api and would like to start implementation for MemchacheQ first. Thanks [1] - http://activemq.markmail.org/search/?q=activemq#query:activemq%20list%3Aorg.apache.activemq.users+page:1+state:facets [2] - http://apache.markmail.org/search/?q=qpid#query:qpid%20list%3Aorg.apache.incubator.qpid-users+page:1+state:facets [3] - http://code.google.com/p/memcacheq/ [4] - http://apache.org/legal/resolved.html [5] - http://aws.amazon.com/free/ On Sat, May 19, 2012 at 12:36 AM, Dulini Atapattu dulin...@gmail.com wrote: Hi Sagara, Thank you very much for the comments you have mentioned and they are a lot helpful to get done the required tasks appropriately and relevantly. I will focus on the activities, queue services and solutions to issues you have mentioned and will provide the community the API design according to the requirements you have mentioned. I added approximate completion dates to my project proposal and they are as follows: - 24th April - 20th May Read about the Apache Qpid, Amazon SQS, Azure Message Queue REST API and3rd party queue frameworks which based on App Engine menarche API (24th April - 30th April). Define the Nuvem message queue API. Discuss with Nuvem community about the design of the API and scope of the project (1st May - 20th May). - 21st May - 12th July Implement above Message Queue API using GAE (21st May to 11th June). Implement above Message Queue API using Amazon (12th June to 03rd July). Preparing for the mid-term evaluation of the project (4th July to 12th July). - 13th July - 12th August Implement Queue API using
Re: GSOC 2012 - Message Queue component for Nuvem
On Thu, May 24, 2012 at 11:54 AM, Dulini Atapattu dulin...@gmail.comwrote: Hi Jean and all, I re-designed the message queue api according to Sagara's comments which was helpful. According to the comments it was reallized that the api should have seperate services representing different tasks, where a given queue service may not support all the services in the api we are providing. According to the information that I read so far, AmazonSQS has the api that provides the most number of services. Thus our api should have separate services to each of those services in AmazonSQS, where then services provided by each other queue service (MemcacheQ etc.) becomes a subset of those services that we may provide with our api. Also this such api provides flexibility to add more services to the api as required and as different queue services may introduce more services or we need our api to be adopted to any other queue service. Thus I would propose the api as follows: *Queue related services:* *createQueue - create a new queue* *deleteQueue - delete the specified queue **listAllQueues - list all the queues* clearQueue - clear the contents of a specified queue clearAllQueues - clear the contents of all the queues *SetQueueAttributes - set the queue related properties* *GetQueueAttributes - get the queue related properties* *GetQueueUrl - get the queue URL* *SetQueuePermission - set queue related permissions* *RevokeQueuePermission - get existing queue related permissions* *Message related services in queues* *SendMessage* - add a message to a specified queue *SendMessages* - add multiple messages to a specified queue *ReceiveMessage - receive a message/ s from a specified queue* *DeleteMessage - delete a message in a queue* *DeleteMessages* - *delete multiple messages in a queue* *ChangeMessageVisibility* - change visibility timeout for the previous received message *ChangeMessagesVisibility* - change visibility timeout for the previous received messages Exceptions will be thrown in our implementations of the above api for different queue services, where the services are not supported according to the queue service. Also I will be considering on implementing the above api for, - GAE: MemchacheQ - AmazonSQS - ActiveMQ (according to my readings so far, ActiveMQ is the mostly being used and more powerful upto now, thus I suppose implementing to ActiveMQ would be much useful [1], [2]) **Also regarding the licenses, MemcacheQ [3] has the New BSD License which is compliant with Apache [4]. I also will be using the AWS Free Usage Tier [5] which provides many services free for one year and where SQS will be free indefinitely, which will be helpful in testing api with Amazon plateform (According to Pasindu Gunarathne). I would like to know the comments about the api and would like to start implementation for MemchacheQ first. Thanks [1] - http://activemq.markmail.org/search/?q=activemq#query:activemq%20list%3Aorg.apache.activemq.users+page:1+state:facets [2] - http://apache.markmail.org/search/?q=qpid#query:qpid%20list%3Aorg.apache.incubator.qpid-users+page:1+state:facets [3] - http://code.google.com/p/memcacheq/ [4] - http://apache.org/legal/resolved.html [5] - http://aws.amazon.com/free/ Hi Dulini, I had promised a few thoughts. Here they are: It looks like you've identified two services: - a queue configuration and management service, allowing you to create, list, delete etc queues programmatically - a message queuing service, allowing you to enqueue and dequeue messages I'd suggest to focus on the message queueing service for now as it's more useful to application logic and queues can usually be configured offline using command line tools or configuration files without having to write code anyway. About your GAE queueing component, I'm not sure how you're planning to use Memcacheq there, as it's written is C and although GAE provides a Memcache service it only supports the Python, Java and Go programming languages. If you want to start with a GAE queuing component (for use in apps running on GAE), I'd suggest to look at the GAE Task Queue service, and in particular their push queue API [6][7]. I'd also recommend to try to simplify a bit your message queuing interface, to help: - Make it portable to different platforms. For example SendMessages, DeleteMessages, ChangeMessageVisibility will map well to the Amazon SQS API but may not be available on other message queuing platforms. - Play well on a scalable Web app platform. IMO a blocking ReceiveMessage call won't scale if you block your Web server threads to wait for queued messages (GAE in particular won't allow you to block their threads), and a non-blocking ReceiveMessage call won't scale either if you need to call it repeatedly poll for messages. So, we may want to think about a more Web-scale friendly programming pattern for receiving messages. - Provide Web remote access
Re: GSOC 2012 - Message Queue component for Nuvem
Hi Dulini, I've started to review your patch, which looks good so far but I'll send a few comments later this evening. In the meantime it'd be good if you could post an email to describe your design, and also give us a few pointers on how to test this. I know you have some test cases but I'm not sure how I could run them. What would I need to configure on an EC2 instance for example? Also, do you have another patch for the GAE implementation that we could review as well? Thanks! - Jean-Sebastien On Wed, Jul 11, 2012 at 8:30 PM, Dulini Atapattu dulin...@gmail.com wrote: Hi Jean and all, I have submitted a patch to JIRA issues for Message Queue Component for Nuvem and I would like to receive any comments regarding that. Also I would like to know whether it is alright to submit my mid-term evaluation to melange now. Thanks On Tue, Jul 10, 2012 at 1:24 PM, Dulini Atapattu dulin...@gmail.com wrote: Hi Jean and all, I have implemented the nuvem-api for message queue component including the interface and other related classes. The api interface is as follows: public QueueMessageHandle sendMessage(QueueMessage queueMessage) throws MessageQueueServiceException; (Sends the queueMessage and returns a handle to the sent message) public ListQueueMessage 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) I also have implemented this interface for Amazon platform, tested with test cases using the account I have created in Amazon Free Usage Tier [14], and also documented the code. I also have submitted the patch for this work at Nuvem JIRA issues [15]. I have also implemented the interface for GAE (using Pull Queue) and currently I am performing the tests for the implementation. I would like to receive any comments about the work I have done so far. Thanks [14] - http://aws.amazon.com/free/ [15] - https://issues.apache.org/jira/browse/NUVEM-14 On Sat, Jul 7, 2012 at 9:41 AM, Sagara Gunathunga sagara.gunathu...@gmail.com wrote: On Sat, May 19, 2012 at 12:36 AM, Dulini Atapattu dulin...@gmail.com wrote: Hi Sagara, Thank you very much for the comments you have mentioned and they are a lot helpful to get done the required tasks appropriately and relevantly. I will focus on the activities, queue services and solutions to issues you have mentioned and will provide the community the API design according to the requirements you have mentioned. I added approximate completion dates to my project proposal and they are as follows: - 24th April - 20th May Read about the Apache Qpid, Amazon SQS, Azure Message Queue REST API and3rd party queue frameworks which based on App Engine menarche API (24th April - 30th April). Define the Nuvem message queue API. Discuss with Nuvem community about the design of the API and scope of the project (1st May - 20th May). - 21st May - 12th July Implement above Message Queue API using GAE (21st May to 11th June). Implement above Message Queue API using Amazon (12th June to 03rd July). Preparing for the mid-term evaluation of the project (4th July to 12th July). Hi Dulini, We are reaching to mid term evaluation very soon. I would like to see codes related to above tasks either on SVN or JIRA, those codes are important to measure project progress for mid term evaluation. I believe Jean will help out to bring your codes to SVN. Thanks ! - 13th July - 12th August Implement Queue API using Apache QPID (13th July - 27th July). Implement simple application to demonstrate the Nuvem Message Queue API (28th July - 6th August). Completing the documentation and test cases (7th August - 12th August). - August 16th - August 23rd Prepare the deliverables for final submission. Thank you, Best regards On Fri, May 18, 2012 at 2:19 PM, Sagara Gunathunga sagara.gunathu...@gmail.com wrote: Please find my in-line answers. On Fri, May 18, 2012 at 12:46 PM, Dulini Atapattu dulin...@gmail.com wrote: Hi Jean and all, With related to the project: Message Queue component for Nuvem, so far I read about AmasonSQS, Azure Queue Service Rest API, MemcacheQ, Sparrow and Depcached. According to details and APIs related to these queue services/ frameworks, all the queue services provide send message and receive message functionality with related to a specified queue, and only some queue services/ frameworks provide other related
Re: GSOC 2012 - Message Queue component for Nuvem
On Fri, Jul 13, 2012 at 12:25 AM, Dulini Atapattu dulin...@gmail.comwrote:
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 ListQueueMessage 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/test.properties file.
- Remove the following line in nuvem-amazon/pom.xml file:
exclude**/AmazonMessageQueueServiceImplTestCase.java/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] -
http://docs.amazonwebservices.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/sqs/package-summary.html
[17] - https://developers.google.com/appengine/docs/python/taskqueue/rest
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,
Re: GSOC 2012 - Message Queue component for Nuvem
Any update?
Thanks
- Jean-Sebastien
On Mon, Jul 16, 2012 at 1:35 AM, Jean-Sebastien Delfino
jsdelf...@apache.org wrote:
On Fri, Jul 13, 2012 at 12:25 AM, Dulini Atapattu dulin...@gmail.comwrote:
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 ListQueueMessage 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/test.properties file.
- Remove the following line in nuvem-amazon/pom.xml file:
exclude**/AmazonMessageQueueServiceImplTestCase.java/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] -
http://docs.amazonwebservices.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/sqs/package-summary.html
[17] - https://developers.google.com/appengine/docs/python/taskqueue/rest
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
[jira] [Commented] (NUVEM-14) Message Queue component for Nuvem
[ https://issues.apache.org/jira/browse/NUVEM-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13440078#comment-13440078 ] Jean-Sebastien Delfino commented on NUVEM-14: - This is progressing. I've started to review the patches and will post some comments and commit part of this code over the weekend. Thanks! Message Queue component for Nuvem -- Key: NUVEM-14 URL: https://issues.apache.org/jira/browse/NUVEM-14 Project: Nuvem Issue Type: Improvement Reporter: Sagara Gunathunga Labels: gsoc2012 Attachments: NUVEM-14.nuvem-api, Nuvem-14-[nuvem-gae-taskqueue].patch, Nuvem-14-[nuvem-standalone-activemq].patch, Nuvem-14-[redesign][nuvem-amazon-sqs].patch, Nuvem-14-[redesign][nuvem-api].patch Message queues are necessary integral of enterprise application. In cloud platform number of vendors provide their own queues components. The aim of this project to provide a standard vendor independent API and implementations for Nuvem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
