I fixed some issues with the new implementation and now it works for putting and retriving messages. I commented out the connection sharing part since there seems be some problems with that. Anyway the connecton shering code should go to Qpid compoent it self so that it can be used by any other commopent.
thanks, Amila. On Tue, Mar 1, 2011 at 10:11 PM, Manjula Rathnayake <manju...@wso2.com>wrote: > Hi, > > On Mon, Feb 28, 2011 at 11:41 AM, Danushka Menikkumbura <danus...@wso2.com > > wrote: > >> You showed some code which useses the client acknowledgment. But not >>> necessarily POC for a possible sqs implementation based on that. Then I >>> asked you to do that to take a decision based on that. Anyway please make >>> the current implementation you have done to work. Then we can see the >>> issues. >>> >> >> :-) I clearly showed using two JMS clients that are listening on the same >> queue how a message becomes invisible to the second when the first one grabs >> a message and it becomes visible to the second when the first releases it. >> So, that is the key JMS behaviour required in order to implement SQS using >> JMS. Anyway Amila as you said let me check what is going wrong in the SQS >> implementation and get it working. (In the mean time I would like to have >> Manjula ack'ed so that I know at least one other person believes its doable >> ;-)) >> > > I remember Danushka used the existing publisher/subscriber sample code to > get messages which are not locked. Anyway, once I tried out earlier similar > thing with set of threads, it did not worked, we got the same locked > message. > > So we will fix the issues with current implementation and get things > working properly, and do some load testing with existing clients. Meanwhile > let s get the code reviewed as well, since last code review we got some > improvements. Those improvements are not fixed in current implementation. I > will work on those soon. > > >> >> >>> I will explain why it is so and why the model I suggested is the proper >>>>>> approach once I have ironed out those functional glitches. >>>>>> >>>>> >>>>> Since it currently functionality wise does not work it may be early to >>>>> review what you have done. But I saw this problem in what you have >>>>> committed. >>>>> >>>>> In your model when some one retrieve a message it keeps the connection >>>>> in memory until user delete the message or timeout. >>>>> >>>>> What append if the server crashes? >>>>> >>>>> For an example. Lets say a user retrieve a message with the visibility >>>>> time out of 120 seconds. After that server crashes and restarts. Now user >>>>> sends a delete request say after 30s. Now how it going to delete the >>>>> message? >>>>> >>>> >>>> So actually deleting is not the issue here Amila. According to the SQS >>>> specification, trying to delete a message using an old receipt handler is a >>>> valid usecase and is kind of idempotent. >>>> >>> >>> Here the senario is user deleting the message within the visibility time >>> out. What you are talking about the user try to delete message after >>> visibility time out. yes the real problem is what you given below. >>> >> >> In SQS, you delete a message using the receipt handle you got when you >> received that message. When you receive a message it becomes invisible. So, >> how can you delete a message that is visible? Maybe I am missing something >> here. >> >> >>> >>> The actual issue is messages locked by one user becoming visible to other >>>> users when server started after a crash. In fact this is an issue when a >>>> queue is shared. >>>> >>> >>> Not necessarily. Lets say first user retrieve a message. Then server >>> crashes and restart. Now user send a delete message within the visibility >>> timeout. Then he try to retrieve the next message. (or else think the same >>> user try to get another message within the visiblity time out before sending >>> the delete message) >>> Anyway we need to support sqs queue sharing as well. >>> >>> >>> >>>> Otherwise duplicate handling should be done at the application level >>>> but not at the Message Broker level IMO. Do you think otherwise? >>>> >>> >>> This is a problem with the method you try to use. If you take the temp >>> queue method. This problem is not there isn't it? >>> Becuase it updates the two queues within a transaction and no state keep >>> in memory. >>> >> >> Do you think the temp queue approach will yield better performance that >> the JMS approach?. If we decide on that then we can continue to use it. My >> only concern is performance. >> >> >>> Please first fix the isuses with the new work you have done. Then lets >>> have a disscussion with Srinath to decide whether we need to consider this >>> or not. >>> >> >> Yes. We also need to decide if the issue you have mentioned (what happens >> if the server crashes) is a concern too. >> >> Danushka >> > > > Thank you. > > -- > Manjula Rathnayaka > Software Engineer > WSO2, Inc. > Mobile:+94 77 743 1987 >
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
