On Sun, Feb 27, 2011 at 12:19 AM, Danushka Menikkumbura <[email protected]>wrote:
> > Then why did you commit it? :). >> > > OK. So, I was fixing the existing SQS kernal and Manjula too was doing some > work (adding SQS error codes, authz, etc) on the same source. > At some point I figured out that merging would become a nightmare if we > continued to make changes and wanted to merge and commit stuff so that we > both could continue the work without any hassle. The SQS module is still in > its early days and I do not think anybody else uses it. Therefore I do not > think a functionality glitch would be a major concern "at this point" unless > there were any build breaks. > > >> As I remember Manjula also did a similar thing but we did not pick that >> since there was those issues with that. >> > > 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 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? In other words this implementation keeps in memory stats which are not persisted. Currently Qpid does not support persistence but we need to have that feature. thanks, Amila. > > Thanks, > Danushka >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
