INFO KMemcached successfully initialized(Questions on its inner workings)

I have a question about System Architecture in wake of 'Memcached' implementation.I read this article and it is not clear for me hoping one of you collaugues can set me right.

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=40646338&objAction=ArticleView

Assume for simplicity I have two livelink servers.ServerA is running the 'Admin' Service as well as Livelink.If I bring up CSIDE on this server just before the message "Server starts on port: 2099".Now if I issue a request I can see it pausing momentarily along

On the other server which does not have Admin Service running I can see this 07:51:02,741 INFO (AdminServerCache).PingServer: Default on [localhost:5858] Connect failed

after about 5s

2015-04-08 07:51:09,091 INFO KMemcached successfully initialized.

(I am frankly puzzled because in my mind I think that Memcached should only work if Admin Service is running,In my case it is not,but I still see success in the above statement.Note I conducted this on my only server)

So really my question is it correct to stop running Admin Service on the FEnd or other servers who are not registered admin servers in the RDB and still get the good things that Memcached promises.

We have an array of about 4 FENDS and about Two real Admin Servers that we are trying to run like this and want to see if Admin Services(Un registered) should run on FENDS or not.

Find more posts tagged with

Comments

Olivier_De_Pooter

Hi Appu,

Memcached is a distributed memory process that needs to be created in the system object volume and be assigned to a registered Admin server. When the admin server hosting the process is not running, this memcached process will not be available. If you have multiple servers with possibility of an admin server, it is adviseable to distribute memcached processes across admin servers to get maximum availability. Simply having an admin server running without assigning the memcached process to it, will not yield any results with regards to memcached. Under ?func=ll&objtype=148&objaction=browse you should find a memcached processes folder where you can add, remove or modify the memcached processes. In general, I prefer using memcached over the regular llcache api.

Appu_Nair1

Thanks.What I think you are confirming is basically what I think is happening.Most livelink clusters will have at least one registered Admin Server if they want search working(people can keep the others running or disabaled it would not matter until you introduce esign to the module list).Keeping values in memcached is primarily the duty of the registered admin server.The other nodes get the values maintained in memcached by interprocess communication.

David Templeton

Most livelink clusters will have at least one registered Admin Server if they want search working(people can keep the others running or disabled it would not matter until you introduce esign to the module list).

No, that has changed, the admin server is no longer for the search processes alone and in fact numerous functions rely on it more. I would say any CS system MUST have at least one admin server deployed. The most obvious reasons are:

<![if !supportLists]>- <![endif]>Search as mentioned

<![if !supportLists]>- <![endif]>Document conversaion service

<![if !supportLists]>- <![endif]>MemCacheD

<![if !supportLists]>- <![endif]>Soon: OTDS

<![if !supportLists]>- <![endif]>Soon: {others to be revealed later}

<![if !supportLists]>- <![endif]>eSign as mentioned

Long are the days of even developers not running the admin server on their dev environments and let’s be clear most development system will have no issue running the admin server. What does this mean in terms of net needing search, well, people will have to learn to go into the interface and stop the dataflow and search processes, that’s all.

Keeping values in memcached is primarily the duty of the registered admin server. The other nodes get the values maintained in memcached by interprocess communication.

This is not correct, the admin servers responsibility is to simply (high level):

<![if !supportLists]>- <![endif]>transfer files

<![if !supportLists]>- <![endif]>manage the stopping and starting of processes, provide status

<![if !supportLists]>- <![endif]>create directories

the communication with the processes themselves for business operations NEVER goes through the admin server it is always directly to the process. For instance, CS knows of the host/ports the memcached servers are running on and communicates directly to them, the same as the search federator and DCS. The CS instances can talk to all of the memcached processes in the cluster equally.

Regards

David

David Templeton

Oliver

You said:

In general, I prefer using memcached over the regular llcache api.

The LLcache api is actually fronted by memcached now, the llcache provides a 2 level cache, first the memcached and then backed by the database. In the case the memcache drops the entry it is then transparent to the solution since it will simply go back to the DB for the data again

David