On Mon, Feb 28, 2011 at 6:02 AM, Danushka Menikkumbura <[email protected]>wrote:
> Hi Amila, > > I am sorry for the Late reply. > > Yes. He did not get it right. The existing implementation (SQS kernal) is >>> crappy and unstable. >>> >> >> It is always better to avoid these terms and based on proper technical >> points. >> > > I should admit in the first place that what I meant was not the way its > coded but the technique that we used - i.e. maintaining two synchronised JMS > queues for each SQS queue and browsing them sequentially - that is crappy > and inefficient :-). It was a collective decision that we took to go ahead > with it when Manjula's POC for the JMS message acknowledgements-based > implementation disprove that it was feasible. But when I took a look back a > couple of days back I realised that it was actually possible. I showed how > it works at the JMS level using a sample implementation to both you and > Manjula (remember? :-)) that day. > 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 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. 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. 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. thanks, Amila. > > Thanks, > Danushka >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
