[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"
by Stan Silvert
JBoss development,
A new message was posted in the thread "Deployment of on-demand web applications":
http://community.jboss.org/message/521946#521946
Author : Stan Silvert
Profile : http://community.jboss.org/people/stan.silvert@jboss.com
Message:
--------------------------------------------------------------
As a compromise, perhaps it's time to revisit the profiles we are shipping. We've talked about having seperate production and development profiles before. Given the discussion above, this is starting to make more sense than ever. Right now we have:
*minimal* - total bare bones
*default* - what most people use, but you have to do stuff like secure the consoel before production
*standard* - as far as I know, this is only for JEE certification?
*web* - just web stuff with JTA, JCA and JPA
*all* - everything we can throw in, but mostly used for clustering
So what if we did something like this?
*minimal* - same as before
*web* - JEE web profile
*standard* - I guess we still need this?
*development* - no admin console and less logging - super-fast boot time - (JSF2 PROJECT_STAGE set to "Development")
*production* - includes admin console - secure - (JSF2 PROJECT_STAGE set to "Production")
*all* renamed to *cluster* (this makes it more obvious what it is really for) - same as production, but with clustered services available
With this, there would be no need for lazy loading.
I bring up the JSF2 PROJECT_STAGE setting because it demonstrates that other projects are going to the Development Mode/Production Mode model. We've talked about this before. It's time to get in front of the trend.
Stan
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521946#521946
14 years, 4 months
[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"
by Remy Maucherat
JBoss development,
A new message was posted in the thread "Deployment of on-demand web applications":
http://community.jboss.org/message/521941#521941
Author : Remy Maucherat
Profile : http://community.jboss.org/people/remy.maucherat@jboss.com
Message:
--------------------------------------------------------------
I am not surprised with the method. As stated in my comments for the relevant bug reports, I dislike it.
- These mechanisms are strongly detrimental in production (massive resource use while user processing is going on, unpredictability of deployment is hidden from the administrator).
- Introduction of volatile ints. I read a performance evaluation where they are more comparable to syncing rather than a simple int. For this usage, I will not use any (production should never lazy load in the first place). The "replaced" flag looks suspicious to me.
- This seems to be done for all webapps, with no way to disable. This should be an opt in mechnism, only enabled for select webapps (with the only one being the admin webapp).
- What do you do with requests piling up while you deploy the actual webapp ?
So you are trying to help the developer here. Please never consider adding these mechanisms to a production oriented server.
Overall, I think the root of the problem is that there's a belief the default profile must ship with such large webapps *and* be run on the slow overpriced macs everyone has bought ...
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521941#521941
14 years, 4 months
[JBoss Portal Development] New message: "Portal authentication against LDAP and fall back to db for admin users"
by Venkateswarlu P
JBoss development,
A new message was posted in the thread "Portal authentication against LDAP and fall back to db for admin users":
http://community.jboss.org/message/521938#521938
Author : Venkateswarlu P
Profile : http://community.jboss.org/people/paturuv
Message:
--------------------------------------------------------------
Hi -
I am trying to configure the JBoss portal 2.7 to authenticate against OPENDS LDAP. The requirement is to have the authentication mechanism against LDAP for normal users and for admin users the authentication need to be against database.
Could some one guide me through seps.
I have already done the following configurations:
In login-config.xml:
1. configured the details for <login-module code="org.jboss.portal.identity.auth.SynchronizingLDAPExtLoginModule" flag="required">
2. configured details for <login-module code = "org.jboss.portal.identity.auth.DBIdentityLoginModule" flag="sufficient">
3. configured details for <login-module code="org.jboss.portal.identity.auth.SynchronizingLoginModule" flag="optional">
In ldap_identity-config.xml
1. given all the necessary configurations to connect to LDAP
In standardidentity-config
1. configured all the other details which are required
I am facing an exception as Bad Password for all the users even though they are present in LDAP or in Database.
Could some one flash some light on this....
Thanks,
Venkat
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521938#521938
14 years, 4 months
[Tomcat Integration Development] New message: "Deployment of on-demand web applications"
by Brian Stansberry
JBoss development,
A new message was posted in the thread "Deployment of on-demand web applications":
http://community.jboss.org/message/521935#521935
Author : Brian Stansberry
Profile : http://community.jboss.org/people/bstansberry@jboss.com
Message:
--------------------------------------------------------------
I've been looking into how to deploy web application's on-demand; i.e. when the first user request that maps to the application comes in.
One of the problems we need to solve to get the boot time of the AS down to a low level is the time it takes to deploy the various web applications we ship by default, particularly the admin console, which is quite heavy. We want to get the deployment time of these war's as low as possible, but some are almost surely always going to take a couple seconds or more to deploy, which is a large fraction of the overall boot time we'd like to see.
An ugly solution is to not include these wars in our default profile; users would have to add them if they wanted them. Not very user-friendly.
An alternate solution is to configure the web server to recognize that certain URLs target an as-yet-undeployed application, and have it call out to the ProfileService to trigger deployment of the web application. Turns out this is fairly straightforward to do. It requires:
1. Fairly simple modification to the JBoss Web logic that maps requests to applications.
2. Integration layer between JBoss Web and ProfileService
3. Registration and activation of on-demand profiles
I'll explain each in more depth
h4. JBoss Web Request Mapping Changes
I've attached a jboss-web.patch that shows the proposed changes.
JBoss Web / Tomcat has isolated the logic for mapping a request to the container it targets into a single class: org.apache.tomcat.util.http.mapper.Mapper. The attached patch modifies that class as follows:
* Adds a new addOnDemandContext(String hostName, String path) method to allow registration of as-yet-undeployed web applications.
* Adds a notification listener interface OnDemandContextMappingListener to Mapper's package.
* Modifies the mapping algorithm such that when a request for an on-demand application comes in, any registered listener is notified. (The listener would presumably deploy the on-demand application, although the logic handles the case where this does not happen.) If the requested container is already deployed this logic adds a single boolean check and a single null check to the critical path, so it's quite lightweight. (The null check could even be removed by adding a return statement.)
* Modifies the logic for when regular (i.e. non-on-demand) applications are registered so it handles the case of the regular context replacing the on-demand context.
The patch doesn't include any unti tests, but the Mapper class is quite amenable to solid unit testing.
h4. Integration layer between JBoss Web and ProfileService
I've attached a tomcat-module.patch that shows the proposed changes.
Basically, this involves implementing the OnDemandContextMappingListener interface and adding hooks to access the JBoss Web Mapper objects so on-demand contexts can be registered and the listener can be registered.
The patch has the TomcatService class do the wiring into JBoss Web, which was the easy approach for this prototype since TomcatService has easy access to the Mappers as it installs the web server. But this could be moved elsewhere if appropriate.
h4. Registration and activation of on-demand profiles
This logic is also included in the attached tomcat-module.patch.
Basically I cut and pasted this from the code that we've been using for a year to handle deployment of the content in clustering's deploy-hasingleton directory. On startup, an MC bean registers a Profile with the ProfileService but doesn't activate it. Later, when the bean gets a signal it activates the profile. In the deploy-hasingleton case, the signal is a change in the cluster topology causing the server to become the "master". Here the signal is the notification from JBoss Web that the context has been requested.
I did a cut-and-paste job here, but this logic should be factored out into re-usable code in one of the ProfileService libraries.
h4. Usage
First, I create a common/deploy folder.
Next, I move each war in server/default/deploy to common/deploy, replacing it with an XXX-activator-jboss-beans.xml file. The wars are admin-console.war, jmx-console.war, jbossws-console.war, invoker.war and ROOT.war.
A typical XXX-activator-jboss-beans.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
<bean name="AdminConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">
<property name="profileService"><inject bean="ProfileService"/></property>
<property name="profileFactory"><inject bean="ProfileFactory"/></property>
<property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>
<property name="contextName">admin-console</property>
<!-- Build a profile from the contents of this single URI -->
<property name="singleURI">${jboss.home.url}common${/}deploy${/}admin-console.war</property>
</bean>
</deployment>
The MC bean exposes some other properties in case you want to do something more sophisticated:
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
<bean name="JmxConsoleActivator" class="org.jboss.web.tomcat.service.ondemand.OnDemandContextProfileManager">
<property name="profileService"><inject bean="ProfileService"/></property>
<property name="profileFactory"><inject bean="ProfileFactory"/></property>
<property name="onDemandContextIntegrator"><inject bean="WebServer"/></property>
<property name="profileDomain">default</property>
<property name="profileServer">default</property>
<property name="profileName">jmx-console</property>
<property name="serviceName">jboss.web</property>
<property name="hostName">localhost</property>
<property name="contextName">jmx-console</property>
<!-- Build a profile from the contents of these URIs -->
<property name="URIList">
<list elementClass="java.net.URI">
<value>${jboss.home.url}common${/}deploy${/}jmx-console.war</value>
</list>
</property>
</bean>
</deployment>
The example above doesn't actually do anything sophisticated; it shows the properties with their default values.
h4. Results
Using a build of the current AS trunk, with the 'default' configuration modified as described above, on my workstation 'default' starts in 20.5 seconds. Unmodified, i.e. with the wars deploying as part of startup, it takes *38.6 seconds*, so an +18.1 second reduction in startup time+. Most of that is from deferring start of the admin-console, but a couple weeks back before the admin-console was restored to trunk I was seeing > 25 seconds boot time on this machine, so it seems moving out the other wars is also saving some time.
Accessing all the on-demand wars with a browser, I saw no noticeable delays on the first request to any of them, except for the admin-console. There there is a 10-15 second delay before the server responds with it's "Redirecting to login page" screen.
h4. Issues
I see a few issues with the above:
1. Need for XXX-activator-jboss-beans.xml. It would be slick to somehow configure the war such that some deployer extracts relevant metadata, detects an "on-demand configuration, wires things up with JBoss Web, and then stops the deployment before anything expensive starts, with deployment continuing when the app is requested. Nice, yes, but much harder. For now I think we should stick to the KISS principle. The "profile activation" approach used here has been in use in the AS for well over a year.
2. Integration with mod_cluster. This is a problem, as mod_cluster will know nothing about the "on-demand" context until the war is actually deployed. So, the load balancer will not know to route requests to the server. This needs fixing, perhaps with a hook into mod_cluster to allow the MC bean to tell it about the on-demand context. I don't think this is a critical problem until AS 6.0.0.CR1 though. We already configure mod_cluster to ignore all the standard apps we deploy; users have to configure ModClusterService to expose them via the load balancer. IMHO until CR1 it's OK to force users who want to expose a standard app to move it back into the deploy/ dir.
3. Virtual host aliases and multiple contexts associated with the same application. The attached prototype doesn't deal with this, but that shouldn't be anything technically difficult to implement.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521935#521935
14 years, 4 months