[Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers
by akluge
Thanks for the comments. I have had a chance to experiment with MINA and build a simple client/server. It did perform better than I expected, which was one of my major concerns with MINA. As a next step I will be implementing a system very similar to the current TCS/TCL (a binary protocol), and see what issues come up.
I expect this to be very adaptable to additional uses; indeed the main reason I am doing this is to allow me to provide additional information asynchronously over the client-server connection, which is very difficult with the current close coupling between the request writing, and the reading of the response.
Right now, the consistent hashing approach seems to meet my needs; however, I am also looking at another approach where the data is partitioned completely on the server side. My main motivation for looking at the server side partitioning as it would make failure recover easier. I see that there is another related discussion on this forum under the memcached client/server title. The data distribution approach I have is very similar to what they discuss, except that I divide the data according to the hash of the key in the key/value pair, and they divide the data according to the hash of the FQN. I considered this, but if the cache is used as a flat cache then all of the data would wind up on one node.
It was also interesting to see the way that MINA registers filters, which is very similar to the way that I will be allowing the registration of requests/responses within the MINA filter. This is to allow the type of extensions to the existing protocol that I mentioned earlier.
Thanks,
Alex
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211195#4211195
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211195
17 years, 1 month
[Design of POJO Server] - Re: Regression on VirtualFile.toURL()
by scott.stark@jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote : That's what I told you yesterday. The URL you are returning is not valid.
| | Its a packed jar not a directory.
| |
| I don't get it anymore.
| Who says this is not valid? The spec?
|
| I thought it was about consistency.
| e.g. have all non-leaves with "/" at the end
|
The main problem is that new URL(".../x/", "y") and URL(".../x", "y") result in two different resolved URLs:
| import java.net.*;
|
| public class x
| {
| public static void main(String[] args)
| throws Exception
| {
| URL dir = new URL("file:/tmp/x/");
| URL file = new URL("file:/tmp/x");
| URL subdir = new URL(dir, "y");
| URL subfile = new URL(file, "y");
| System.out.println(subdir);
| System.out.println(subfile);
| }
| }
|
| ... output:
|
| file:/tmp/x/y
| file:/tmp/y
|
This is what Carlo is saying about how the relative url against the jar is being resolved.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211193#4211193
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4211193
17 years, 1 month