Hi Bongjae,
wow, you did a lot of work, I'm really impressed!
Here are some notes I have:
--------------------------------------------------------------------------------------------------------------------------------------------------------
1) GrizzlyMemcachedCacheManager may have a state flag to forbid its
usage after/during shut down.
For example if you look at shutdown method, it looks like under certain
conditions, when one of the threads call shutdown() and another calls
addCache(), it's possible that newly created Cache will stay in the
caches map and never get closed.
2) GrizzlyMemcachedCache.CONNECTION_POOL_ATTRIBUTE_NAME
was there specific reason to use String-based attributes? IMO Grizzly
org.glassfish.grizzly.Attribute-based access might be faster. (may be it
was due to AttributeBuilder bug you found?)
3) EvictionTask
IMO it could be optimized, may be we shouldn't take snapshot and use
queue.size() method (which is pretty heavy for LTQ). May be it might be
enough to use pool.queue directly and poolSizeHint value as pool size?
4) MemcachedClientFilter.handleWrite(...)
When we write to the same connection from multiple threads at the same
time, we can break request-response correlation... and unfortunately
this issue can not be fixed at the moment.
The problem is that you have a request queue, where adding requests
during the MemcachedClientFilter.handleWrite(...) execution. Then, when
processing response, you peek a request from a queue and get
request-response pair.
But if write() method is called from different threads, the order we add
requests to the requests queue may be different than order these
requests will be sent on wire. To fix this issue, we have to add
requests to the queue right before specific request is going to be sent
on wire. This is not doable for now :(
I have a fix for this in my local repo, but don't want to commit it for
2.2.2 release, cause it includes API changes. I'm going to commit the
fix right after 2.2.2 release.
Lets just keep this issue in mind (or better file in JIRA :) ) and fix
it in Grizzly 2.3?
--------------------------------------------------------------------------------------------------------------------------------------------------------
In you handleWrite method, I noticed optimization flag to switch from
single to composite buffer usage. Just curios, do you have any numbers
to share, which approach works better in which conditions?
Thanks a lot!!!
WBR,
Alexey.
Post by Bongjae ChangHi Alexey,
I commited them. And I will continue to update, benchmark and optimize them.
If you can review them and find bugs or improvement points, please let
me know or fix them(Maybe I think that it is not easy for you to
review them now because they don't have documents and javadoc yet. I
will update them as soon as possible). :-)
Thanks!
Regards,
Bongjae Chang
Date: Wed, 18 Jan 2012 13:37:16 +0100
Subject: Re: Initial commit of grizzly-memcached
Hi Bongjae,
Post by Bongjae ChangHi,
I am trying to support memcached client based on Grizzly.
Now, I tested only basic commands. But I should do more works such as
making javadoc, benchmarking with other clients, optimizing it and
etc...
So, could I commit them first in grizzly/extras/memcached like
grizzly/extras/thrift?
Sure, go ahead.
Thank you very much!
WBR,
Alexey.
Post by Bongjae ChangThanks.
Regards,
Bongjae Chang