Forget this one, I understood why you say I am overengineering this in the other post. I read this one first since it gets listed on top in the forum. So let me try to get the Ghetto Locking in place.
On Saturday, June 4, 2016 at 3:40:09 PM UTC+5:30, Nishant Varma wrote: > > Thanks. Can you please tell me why you say that I am overengineering. > Maybe I am but I wanted good reasons so that I convince myself. The problem > is some times locks are not happening like say 2-3 times out of 3000 > requests, and I have only 4 reasons so far - 1) get-set race 2) memcache > client disconnects 3) data eviction 4) some ordinary coding issues (of > which I don't see any evidence so far and the ratio suggests otherwise?). > Also do you have any other ideas to take this forward, let me know. I > wanted to see if it is set-get race mainly or else just rule out > concurrency as the first step. > > On Saturday, June 4, 2016 at 1:35:37 PM UTC+5:30, Dormando wrote: >> >> Hey, >> >> Memcached can't do that easily right now. You can use the STDOUT logging >> but that requires reading everything the server is doing directly. >> >> I started a branch for a better logging situation a few months ago, and >> am >> picking it up to finish over the next few weeks >> (https://github.com/memcached/memcached/pull/127). That won't do you any >> good in the short term though. >> >> Printing via your overrides is probably the best way of getting the >> localized data you need, however I insist *again* that you're >> overengineering this. >> >> On Sat, 4 Jun 2016, Nishant Varma wrote: >> >> > Real time of offline solutions would be helpful. If I can profile in >> background and query it later that is one option. However the only concern >> with profiling is that I don't >> > need to profile everything. Or does memcache do this by default? Can >> anyone guide me? >> > >> > On Saturday, June 4, 2016 at 12:13:32 PM UTC+5:30, Nishant Varma wrote: >> > I am trying to troubleshoot an issue which could happen because >> of get-set race condition. I can monitor the entire memcache operations but >> I guess it is going to >> > be huge because its a small percentage of the DB itself, so I >> need to filter only the keys I am interested in. We have a namespacing >> convention to distinguish our >> > memcache entries so I would like to monitor the get and set that >> happens to a specific namespace to track the get-set race condition. >> > >> > >> > I have a client side solution which is to over-ride (decorator in >> Python) memcache.get and memcache.set to print the arguments if the key >> matches our desired >> > pattern. >> > >> > >> > However can this be done in memcache server? We have so many >> clients and we would have collect this information from all nodes and >> morover this feels like suited >> > for server. Is there something that we could in memcached like >> using debug module that would help us? >> > >> > >> > This e-mail message (including any attachments) may contain information >> that is confidential, protected by the attorney-client or other applicable >> privileges, or otherwise >> > comprising non-public information. This message is intended to be >> conveyed only to the designated recipient(s). If you have any reason to >> believe you are not an intended >> > recipient of this message, please notify the sender by replying to this >> message and then deleting it from your system. Any use, dissemination, >> distribution, or reproduction of >> > this message by unintended recipients is not authorized and may be >> unlawful. >> > >> > -- >> > >> > --- >> > You received this message because you are subscribed to the Google >> Groups "memcached" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- This e-mail message (including any attachments) may contain information that is confidential, protected by the attorney-client or other applicable privileges, or otherwise comprising non-public information. This message is intended to be conveyed only to the designated recipient(s). If you have any reason to believe you are not an intended recipient of this message, please notify the sender by replying to this message and then deleting it from your system. Any use, dissemination, distribution, or reproduction of this message by unintended recipients is not authorized and may be unlawful. -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
