Community
Participate
Working Groups
The RSE server serves single client, so that the number of processes increases as the number of clients increases. The requirement is to make the RSE server extendable to serve multiple clients to eliminate the number of processes. The basic approach is that a daemon creates a thread for each client and runs the server in the thread. The daemon is supposed to be provided by system vendors for each system. The following considerations need to be solved. - Authorization of thread The server thread needs to run with the authorization of the client. Any threads created by a miner also needs to run with the authorization of the client. Since the thread authorization mechanism is system dependent, it is to be made extendable. - Authorization of process Any processes created by a miner needs to run with the authorization of the client. The process authorization mechanism is also to be made extendable. - Thread safety Access to global variables needs to be serialized. - The server termination The server needs to be terminated without affecting other threads. Also the server needs to be terminated without leaving uncollectible garbages. - The user specific values The use of user specific values needs to be limited within thread scope. The server cannot rely on the user specific system properties.
My biggest concern with this request is authorization and security. * Threads, per definition, run in the same memory partition (whereas a processes has memory of its own - that's the main difference between a Thread and a Process). So, if threads for multiple unrelated clients run in the same memory space, it seems that a malicious client A could write some miner that reads process memory to read (or influence) behavior of client B. In fact the main difference between current dstore behavior and the requested behavior is that what's a process now should become a Thread in the future. Is there really a burning need to make this happen? - This seems a major undertaking, and I'm very unsure if this can be squeezed into 3.0. Please explain why there is a need to reduce the number of processes. It looks like your dstore daemon runs on a multi-user machine, and users are expected to work on that machine so they would for processes of their own anyways (shells, compilers, ...). So I can't see a lot of benefit from such a change, but I do see a lot of risk and compromized security. Note that even servers like cvs or Apache httpd fork off separate processes in order to perform their work. I'm inclined to mark this WONTFIX.
The background of this requirement is a scalability issue. When the dstore server runs in a process, it takes about 20MB to connect. On the other hand, when it runs in a thread, it takes +0.2MB to connect. The difference becomes significant when thousands of clients need to be supported. The difference between dstore and httpd is that the spawned server process is long running process and thus keeps its memory longer. The security needs to be considered by system vendors, so that any unauthorized codes are not executed. The requirement does not change the default behavior of the dstore server. The dstore can run either in a process or thread. It is up to a daemon that a system vendor provides to decide which way it runs.
Ok, I understand the scalability issue. Still - given that security should be top priority and the OS facilities should be used for security - I'd recommend exploring all possible options. For instance: * gcj supports compiling Java into native shared libs (DLL's). Such DLL's can then share their code in memory among multiple processes. Should allow reducing the resident process size per user of the JVM. * I've heard that the IBM JVM also supports a shared classfile mode. I don't fully understand it, but could it be that it supports sharing the in-memory representation of JARs and .class files among multiple processes? That would also reduce process size of the JVM. * Could it be that from your 1000 users, many are actually idle most of the time and could be killed by an idle timer with automatic restart on reconnect? Just some ideas... when your OS supports secure operations even in Threads, and you can come up with a good API to make the dstore daemon extensible to do what you need I'm certainly open for your suggestions too.
Your options needs to be considered even one server serves multiple clients, because of the system limitation for a number of concurrent threads in a process. It is up to the daemon, provided by the system vendor, that manages multiple server processes and performs workload balancing across them.
Created attachment 93838 [details] patch to provide dstore api changes needed to support mulitple clients to single process server This patch contains the changes needed to support the single process dstore server for multiple clients. It does not contain the extensions needed to run in this mode, however that is platform-specific and for IBM's purposes will be provided at the product level. I've looked at the code and have had to change a couple things for cleanup, but for the most part things look sound to me. I've tested this out using the one process per client approach (as we've done historically) and this works. Since this involves API, we'll need to get this in soon.
Created attachment 93840 [details] updated patch I submitted the wrong stuff in the last patch. Here's the corrected one.
Dave I assume that this contribution is not from yourself. Can you please specify who the author(s) are and have them give their legal message that they are contributing under EPL, and did not reference any 3rd party code unless under EPL. Usually I'd prefer the original contributor attach the patch because by using bugzilla themselves, they implicitly agree to the Eclipse Website Terms of Use.
Changes look good to me over all, just few minor issues: * Receiver.java just changes copyright year without any modification. * For the new files, were they all initially written in 2008 or should the copyright indicate an earlier year? * "@version initial" should be removed, this is no standard javadoc tag. (We prefer using @since) * IServerLogger is missing Javadoc It looks like there's not so much breaking API change after all. I could only spot the ServerLogger now using instance methods rather than static ones, the rest should mostly be compatible. The new Eclipse API Tooling could help figuring out what kinds of API are really broken. If we get lots of breakage that clients (i.e. miners) need to adapt to anyways, I think I'd like to rename ICancellableHandler into ICancelableHandler.
(In reply to comment #7) > Dave I assume that this contribution is not from yourself. Can you please > specify who the author(s) are and have them give their legal message that they > are contributing under EPL, and did not reference any 3rd party code unless > under EPL. Usually I'd prefer the original contributor attach the patch because > by using bugzilla themselves, they implicitly agree to the Eclipse Website > Terms of Use. This contribution originally came from Masao Nishimoto and Noriaki Takatsu from IBM, although I had to make some modifications. I'm not sure who made which individual change or whether there was anyone else involved. Masao, could you confirm who changed what and what we should use for the legal message? Thanks
No need to worry about wording of the Legal message if the contribution was made by IBM employees (i.e. same company as you, the committer) under supervision of a committer (i.e. yourself). I just need you, Dave, to ensure that the entire contribution was written from scratch under EPL or by referencing EPL'd code only. Take care that referencing Javadocs from original Sun API Docs can also be seen as Copyright infringement (talking about SecuredThread Javadocs - I did not check whether this is a verbatim copy of Javadocs from the Sun API Sources).
(In reply to comment #8) > Changes look good to me over all, just few minor issues: > * Receiver.java just changes copyright year without any modification. > * For the new files, were they all initially written in 2008 or should > the copyright indicate an earlier year? > * "@version initial" should be removed, this is no standard javadoc tag. > (We prefer using @since) > * IServerLogger is missing Javadoc > It looks like there's not so much breaking API change after all. I could only > spot the ServerLogger now using instance methods rather than static ones, the > rest should mostly be compatible. The new Eclipse API Tooling could help > figuring out what kinds of API are really broken. > If we get lots of breakage that clients (i.e. miners) need to adapt to anyways, > I think I'd like to rename ICancellableHandler into ICancelableHandler. Apparently there were a few missed code changes (including for Receiver) but I've made the appropriate updates for that. I'll fix the copyrights and javadoc.
Created attachment 93982 [details] patch with updated copyrights and javadoc
I've committed the patch to cvs.
Breaking API Changes according to API Tooling: org.eclipse.rse.services.dstore: * Removed UniversalServerUtilities#getUserPreferencesDirectory() * Added "DataStore" parameter to UniversalServerUtilities#log*() methods org.eclipse.dstore.core: * Removed ClientConnection#connectDaemon(int) * Removed DataStore#getDomainNotifier() I'm OK with the changes in rse.services.dstore since these seem to be necessary in order to support multi-threaded operation. But what about the ones in dstore.core ? We could remain at version dstore.core_2.1.0 if these changes can be made in a backward compatible manner.
(In reply to comment #14) > Breaking API Changes according to API Tooling: > org.eclipse.rse.services.dstore: > * Removed UniversalServerUtilities#getUserPreferencesDirectory() > * Added "DataStore" parameter to UniversalServerUtilities#log*() methods > org.eclipse.dstore.core: > * Removed ClientConnection#connectDaemon(int) > * Removed DataStore#getDomainNotifier() > I'm OK with the changes in rse.services.dstore since these seem to be necessary > in order to support multi-threaded operation. But what about the ones in > dstore.core ? We could remain at version dstore.core_2.1.0 if these changes can > be made in a backward compatible manner. connectDaemon(int) was changed to connectDaemon(int,int) so that the timeout could be specified. I suppose we could add the old signature back (as deprecated) to avoid breaking it. getDomainNotifier() was changed to return an IDomainNotifier so that DomainNotifier could be internal.
Marking this a fixed.
IP records - Noriaki Takatsu, IBM Japan, takatsu@jp.ibm.com, Office Address: 1623-14, Shimotsuruma, Yamato-shi, Kanagawa Office phone: 81-46-215-5379 Legal Message: I, {Noriaki Takatsu}, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer to make this contribution under the EPL.
Noriaki, if you are still listening... for tracking purposes, would it be possible that you download the patch and re-attach with your ID ?
Created attachment 196617 [details] Reattach for tracking purposes
Comment on attachment 196617 [details] Reattach for tracking purposes Thanks!
