Forum OpenACS Development: TCP Connection pooling

Collapse
Posted by Harish Krishnan on
Hi all,
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?

Collapse
Posted by Andrew Piskorski on
Connection pooling to what? I assume you are not writing any C code, but instead want to do this entirely from Tcl using either the Tcl socket, AOLserver ns_socket, or similar commands. This is definitely a Tcl and/or AOLserver question, you need to ask them, this has nothing directly to do with OpenACS. What you want is to "share Tcl channels" between multiple threads. By default, you cannot do this.

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.

Collapse
Posted by Harish Krishnan on
Hi Andrew.. We had implemented a TCL API for memcacheD . When I was trying to integrate it with openacs I realized that I had to open a socket connection for each thread/connection. Hence I was figuring out a way to keep the socket alive between threads and pass it around.

Thanks for the information.

Collapse
Posted by Andrew Piskorski on
Ah, I see Harish, you're probably picking up on the work you first mentioned a year ago. Tom Jackson's NetV prototype and Memcached were also discussed in that thread. Is your memcached Tcl API publically available anywhere? It sounds useful.
Collapse
Posted by Harish Krishnan on
Andrew I would make it available publicly soon, I am currently tied up a couple of important issues.
Collapse
4: Re: TCP Connection pooling (response to 1)
Posted by Malte Sussdorff on
Are you integrating it with the OpenACS DB Api (e.g. by using a -memchachetime parameter)?

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.

Collapse
Posted by Harish Krishnan on
"Are you integrating it with the OpenACS DB Api (e.g. by using a -memchachetime parameter)?"

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.
for example:

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.

Collapse
8: Re: TCP Connection pooling (response to 1)
Posted by Harish Krishnan on
I added a preliminary version of the TCL api for memcached that a couple of interns developed for improving caching here [1].

[1] https://openacs.org/storage/download/?file%5fid=312257
There is a test script along with it.

Collapse
9: Re: TCP Connection pooling (response to 8)
Posted by Hamilton Chua on
Hello Harish,

Can you upload the tcl api for memcached again, please ?

Thanks,

Hamilton

Collapse
Posted by Torben Brosten on
Hi Hamilton,

Try substituting http://209.162.194.125/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.