Memcached two models. NET client's depressing thing

Soon will be responsible for a relatively large project, how big? It's pretty big anyway. Now in the preparatory stage, I am mainly responsible for the system framework, in the system cache this piece decided to use the HTTP runtime cache +memcached.

Memcached has been used a few times before, but also is a type of, not yet formally large-scale applications. This is also a rare practice of mobile phone will it. The memcached server is intended to be distributed across the Web application server and the database server.

(two servers have a bit of a big spending on two Dell PowerEdge R810 customized configurations about a single 65,000).

About Memcached. NET client selection this piece, there are mainly two candidate libraries, memcached.clientlibrary (discuz. NET version of the Enterprise Edition used by the cache client) and Enyim.

These two types of libraries are more useful, the latter is more convenient to use, just simple configuration. I have chosen Enyim.

A common problem was found in testing, if, when using multiple memcached services, when one of the server networks is not available (and at least one other memcached service exists),

The cache function of the memcached.clientlibrary fails, and Enyim does not process the connection timeout when the socket object is instantiated during the cache operation (Memcached.clientlibrary processed).

It is generally necessary to wait more than 10 seconds for the thread to continue and the thread to be stuck. In previous applications, memcached and the web coexist on a single server, so there's no such thing as

But this time I'm going to open a memcached instance on the Web server and open a memcached instance on the database server, so I'm concerned about the problem. In general, this problem will not have much effect,

But my heart always feels bad. Do not intend to use memcached.clientlibrary, so find the source code of Enyim, intend to modify it yourself.

Looking over the source code, Enyim's problem mainly exists in Enyim.Caching.Memcached.PooledSocket, which is mainly used to create socket connections.

The following are the constructor functions

12345678910111213141516171819202122232425262728293031

internalPooledSocket(IPEndPoint endpoint, TimeSpan connectionTimeout, TimeSpan receiveTimeout, Action<PooledSocket> cleanupCallback)         {              this.endpoint = endpoint;               this.cleanupCallback = cleanupCallback;               this.socket = newSocket(endpoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);                this.socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.SendTimeout, connectionTimeout == TimeSpan.MaxValue ? Timeout.Infinite : (int)connectionTimeout.TotalMilliseconds);              this.socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReceiveTimeout, receiveTimeout == TimeSpan.MaxValue ? Timeout.Infinite : (int)receiveTimeout.TotalMilliseconds);               // all operations are "atomic", we do not send small chunks of data              this.socket.NoDelay = true;                this.socket.Connect(endpoint);              this.inputStream = newBufferedStream(newBasicNetworkStream(this.socket));      }

Because the socket (I'm almost illiterate about the socket), the object cannot set properties such as the connection timeout (how to do this), and can be seen in the source code this.socket.Connect (endpoint)

Did not do any processing, resulting in a longer thread waiting when connecting to the problematic service. I looked for it on the internet and found a solution like this, which is to use the thread pool.

Online Search for code repair modification is almost ready to use, created a Enyim.Caching.Memcached.SocketConnector, which has a core static method, used to create the socket object, and run the definition time-out.

1234567891011121314151617181920212223242526272829303132333435

publicstaticSocket GetConnectdSocket(IPEndPoint endpoint, TimeSpan connectionTimeout, TimeSpan receiveTimeout, intmillisecondsTimeout)        {            ConnectorState state = newConnectorState();            state.Endpoint = endpoint;            state.ConnectionTimeout = connectionTimeout;             state.ReceiveTimeout = receiveTimeout;            ThreadPool.QueueUserWorkItem(newWaitCallback(SocketConnector.ConnectThreaded), state);            if(state.Completed.WaitOne(millisecondsTimeout, false))             {                if(state.Socket == null)                {                    throwstate.Exception;                }                returnstate.Socket;            }            state.Abort();            thrownewSocketException(0x2af9);        }

Then modify the structure of the Pooledsocket to:

12345678910111213

internalPooledSocket(IPEndPoint endpoint, TimeSpan connectionTimeout, TimeSpan receiveTimeout, Action<PooledSocket> cleanupCallback)         {            this.endpoint = endpoint;            this.cleanupCallback = cleanupCallback;            this.socket = SocketConnector.GetConnectdSocket(endpoint, connectionTimeout, receiveTimeout, 100);            this.inputStream = newBufferedStream(newBasicNetworkStream(this.socket));        }

I set the connection timeout to 100 milliseconds, and that disgusting problem was basically solved.

Memcached two models. NET client's depressing thing