Forum OpenACS Development: TCP Connection pooling
I am trying to implement a simple TCP connection pooling mechanism for a project. I want to create a set of "global" sockets and enable all threads use the sockets serially. Each of these sockets connect to an external server.
How can I share sockets across connections/threads in Aolserver?
However, I do vaguely remember this coming up before on the AOLserver list before (e.g., July 2003, Nov. 2002, July 2002) and people have independently solved this at least twice, likely three times.
I would first check the latest versions of the Tcl Threads Extension. From its latest docs it does not seem to support passing channels between threads, but you might want to ask Zoran (its maintainer). He no doubt is much more familiar with all this channel passing stuff, both in Tcl and in AOLserver.
If the Tcl Threads extension does not support channel sharing/passing between threads, then I would check out the older nssharechannel or dqd_utils AOLserver modules, which definitely do support this. There's also the AOLserver 4.x ns_chan command, mentioned in some the threads above.
Thanks for the information.
What is the benefit over using util_memoize?
Wouldn't it make more sense to write a database driver for memchacheD and first query the memcacheD Pool (if the query should be cached) and as a second try hit the database itself.
Also, I think Don had some ideas on database caching.
No I am not doing that right now. My idea currently is to add another layer between local cache and actual proc execution within util_memoize. This layer queries a set of centralised caching servers for a "key" and updates the local cache.
The advantage is to enable centralized caching in a multiserver environment. This also helps in a ready cache being available for every server in the cluster after it restarts. Aolserver Network variable or a shared memory for multiple servers isnt yet available so I decided to have memcached do the job though ideally the NV feature in Aolserver would be a far cleaner solution.
"Wouldn't it make more sense to write a database driver for memchacheD"
I dont think so. I appreciate the issue we might have if we use db API + memcacheD+bind variables ( specifically db_string ) but the issue is same even if we use db API+util_memoize+bind variables.
util_memoize [db_string myquery "select name from users where user_id = :user_id"]will create problems because of lack of unique "key". Having memcacheD or not having it doesnt make a difference here. So the smarter thing is not use such a combination in your application currently. I think the someproc and someproc _not_cached way of dealing with db_string would suffice for now ( I dont know where else we would have issues apart from db_string ).
The memcacheD parameter option for DB API would too much work for a small issue.
There is a test script along with it.
Can you upload the tcl api for memcached again, please ?
Try substituting http://184.108.40.206/storage/ wherever you see https://openacs.org/storage/ for older file storage urls. Apparently the current storage has not been repopulated from that backup yet.