UserConfig: alternative implementation

View: New views
5 Messages — Rating Filter:   Alert me  

UserConfig: alternative implementation

by Mikhail Kryshen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I have implemented host event listener similar to
org.apache.catalina.startup.UserConfig but with support for multiple
webapps per user, automatic deployment and remote user databases on UNIX.

Currently it is available as a separate package that could be added to
tomcat6 classpath and referenced in server.xml.

Description: http://kryshen.net/userconfig/
Code: http://kryshen.net/userconfig/userconfig-latest.tar.gz

Implementation details:
Abstract class UserConfig extend HostConfig to reuse automatic deployment
functionality. Two concrete implementations of UserConfig are provided:
PasswdUserConfig uses local passwd file or getent command to list users
and HomesUserConfig reads user home subdirectories in the specified base
directory.

I do not think it makes sense to have separate UserDatabase
interface like in current Tomcat implementation because of tight
coupling between the classes: UserDatabase requires UserConfig to access
configuration properties and UserConfig have to have all properties
needed by all UserDatabase implementations.

I could contribute this code as a patch, but need to resolve some issues:
- my implementation is not compatible with current UserConfig in Tomcat
(brake compatibility or name it differently and provide as an alternative
to the original UserConfig?);
- it may be better to separate HostConfig methods useful for UserConfig
in an abstract class to be extended by HostConfig and UserConfig;
- javadoc comments may need correction (I'm not native English).

--
Mikhail

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: UserConfig: alternative implementation

by Costin Manolache-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Curious: how does it scale for large number of users, in particular if you
have NFS homes ?

It would be interesting to change this to not init the contexts when tomcat
starts - just register a handler that would start the context on first
request.
Or as a Valve that looks for ~foo and then lookups and start the context for
that user on demand.

IMHO this could be a nice feature - but it's a perfect example of thing that
shouldn't be bundled in tomcat, but
available as a separate download. And if it used a scheme like /user/foo -
it may even be possible to implement it as a app+standard filter, with just
one 'internal API' call to load the context.

Costin


On Tue, Nov 3, 2009 at 3:16 PM, Mikhail Kryshen <mikhail@...> wrote:

> Hi,
>
> I have implemented host event listener similar to
> org.apache.catalina.startup.UserConfig but with support for multiple
> webapps per user, automatic deployment and remote user databases on UNIX.
>
> Currently it is available as a separate package that could be added to
> tomcat6 classpath and referenced in server.xml.
>
> Description: http://kryshen.net/userconfig/
> Code: http://kryshen.net/userconfig/userconfig-latest.tar.gz
>
> Implementation details:
> Abstract class UserConfig extend HostConfig to reuse automatic deployment
> functionality. Two concrete implementations of UserConfig are provided:
> PasswdUserConfig uses local passwd file or getent command to list users
> and HomesUserConfig reads user home subdirectories in the specified base
> directory.
>
> I do not think it makes sense to have separate UserDatabase
> interface like in current Tomcat implementation because of tight
> coupling between the classes: UserDatabase requires UserConfig to access
> configuration properties and UserConfig have to have all properties
> needed by all UserDatabase implementations.
>
> I could contribute this code as a patch, but need to resolve some issues:
> - my implementation is not compatible with current UserConfig in Tomcat
> (brake compatibility or name it differently and provide as an alternative
> to the original UserConfig?);
> - it may be better to separate HostConfig methods useful for UserConfig
> in an abstract class to be extended by HostConfig and UserConfig;
> - javadoc comments may need correction (I'm not native English).
>
> --
> Mikhail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

Re: UserConfig: alternative implementation

by Mikhail Kryshen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, 3 Nov 2009 16:34:57 -0800
Costin Manolache <costin@...> wrote:

> Curious: how does it scale for large number of users, in particular if you
> have NFS homes ?

I use it at a university server with 780 user accounts with home
directories mounted via NFS from distinct file server, user database is
LDAP. Reading the remote user database and checking all home directories
for webapps takes about 100 ms of real time.

Performance for the large number of deployed webapps would likely be the
same as with the original tomcat UserConfig or Host having all the apps
in a single appbase.

> It would be interesting to change this to not init the contexts when tomcat
> starts - just register a handler that would start the context on first
> request.
> Or as a Valve that looks for ~foo and then lookups and start the context for
> that user on demand.

Most contexts will probably start soon anyway since every user would want
to check his/her webapp after it is installed. Then to make this approach
useful some checking for long-ununsed contexts would be required or
periodic tomcat restarts to clean-up. Anyway it would be interesting
thing to implement.

> IMHO this could be a nice feature - but it's a perfect example of thing that
> shouldn't be bundled in tomcat, but
> available as a separate download. And if it used a scheme like /user/foo -
> it may even be possible to implement it as a app+standard filter, with just
> one 'internal API' call to load the context.

For me it's not a problem to support this as a separate package, but
tomcat already have such a thing bundled which is not currently very
useful.

--
Mikhail

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: UserConfig: alternative implementation

by Costin Manolache-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, Nov 4, 2009 at 6:47 AM, Mikhail Kryshen <mikhail@...> wrote:

> On Tue, 3 Nov 2009 16:34:57 -0800
> Costin Manolache <costin@...> wrote:
>
> > Curious: how does it scale for large number of users, in particular if
> you
> > have NFS homes ?
>
> I use it at a university server with 780 user accounts with home
> directories mounted via NFS from distinct file server, user database is
> LDAP. Reading the remote user database and checking all home directories
> for webapps takes about 100 ms of real time.
>
>
I was asking about tomcat startup time - loading all the 780 contexts,
versus a normal
startup with 2-3 contexts. BTW - it would be nice to include this kind of
info in the docs.



> Performance for the large number of deployed webapps would likely be the
> same as with the original tomcat UserConfig or Host having all the apps
> in a single appbase.
>
>
> It would be interesting to change this to not init the contexts when
> tomcat
> > starts - just register a handler that would start the context on first
> > request.
> > Or as a Valve that looks for ~foo and then lookups and start the context
> for
> > that user on demand.
>
> Most contexts will probably start soon anyway since every user would want
> to check his/her webapp after it is installed. Then to make this approach
> useful some checking for long-ununsed contexts would be required or
> periodic tomcat restarts to clean-up. Anyway it would be interesting
> thing to implement.
>

780 users each accessing his app every time tomcat starts ? I doubt it.
You're right, stopping long-unused contexts would be another nice thing.



>
> > IMHO this could be a nice feature - but it's a perfect example of thing
> that
> > shouldn't be bundled in tomcat, but
> > available as a separate download. And if it used a scheme like /user/foo
> -
> > it may even be possible to implement it as a app+standard filter, with
> just
> > one 'internal API' call to load the context.
>
> For me it's not a problem to support this as a separate package, but
> tomcat already have such a thing bundled which is not currently very
> useful.


Well, since we'll have a major release - it is possible to move what used to
be bundled ( and not
currently very useful or used by lots of people ) to separate packages that
can be
better supported.

Costin

Re: UserConfig: alternative implementation

by Mikhail Kryshen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, 4 Nov 2009 10:46:07 -0800
Costin Manolache <costin@...> wrote:

> I was asking about tomcat startup time - loading all the 780 contexts,
> versus a normal
> startup with 2-3 contexts. BTW - it would be nice to include this kind of
> info in the docs.

Tried the following test setup:
1000 users, 1 application per user (copies of the same application with
several servlets and jsp's), homes on NFS, HomesUserConfig listener.

Deployment at startup: 2 min 15 s.
Periodic checks for new/deleted/updated apps: 500-1000 ms.
Java process memory (no sessions opened): 463 M.

Software and hardware details:
Xen virtual machine on Intel Xeon 2.5 GHz, Linux 2.6.27.37
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
Apache Tomcat 6.0.18

--
Mikhail

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...