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. > 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. 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. Otherwise duplicate handling should be done at the application level but not at the Message Broker level IMO. Do you think otherwise? Thanks, Danushka
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
