Tag Archive: JBoss


from jboss wiki

OutOfMemoryExceptions

This section attempts to cover some of the most common reasons why you may see an OutOfMemoryError from your JBoss application server. Interestingly, there are several cases where the JVM may report an OutOfMemoryError even if it is not really out of all of its available memory. For example, most modern Java virtual machines segment the memory heap into generations. Your virtual machine may complain about lack of memory when it has only exhausted one segment (a specific generation) from its total maximum heap size. Also under some conditions on Linux/Unix systems running out of some Operating System resources may yield an OutOfMemoryError for example the inability for the OS to create more new threads for the JVM).

Of course, it is also possible to get an old fashioned OutOfMemoryError when your Java virtual machine really does run out of its maximum heap. There could be few reasons for this, for example you may have a cache configuration that allows more instances to be kept in memory than the JVM really can fit into its heap. Or it may be simply that your JVM has been configured with a maximum heap size too small to run all your application server services.

Seemingly Bogus OOMEs

Running out of memory generates an Error that is not likely to be masked in a catch block because it is an Error rather than an Exception. This is important since one often sees theories expressed about OutOfMemoryError being reported erroneously. That is very unlikely, although OOMEs do occur when the heap has plenty of memory or plenty of recoverable memory.

An OOME is also thrown when the permanent memory is exhausted and that is not part of the heap per se. That is a JVM specific area of memory where information on loaded classes is maintained. If you have a mountain of classes (e.g, a lot of EJBs and JSP pages) you can easily exhaust this area. Oftentimes an application will fail to deploy or fail to redeploy. Increase your permanent memory space as follows to avoid OOMEs. The default with the -server switch is 64 megabytes:

  • -XX:MaxPermSize=128m (Note this is in addition to the heap. In this case we have 512M heap, 128M permanent space for a total of 640 megabytes. Don’t forget the JVM itself takes up a chunk of system memory and there is also two megs per thread of stack space. That can add up with a lot of HTTP/S processors.)

  • -XX:MaxPermSize=128m -Xmx512m (total of 640 megabytes allocated from system – this is not the total size of the VM and does not include the space the VM allocates for the “C heap” or stack space)

On Windows, you can set this in the \bin\run.bat file:

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:MaxPermSize=128m

WebLogic appears to have finally determined this was the source of the common OOME reports resulting from their heavy EJB footprint: loads the EJBC compiled classes and has an overall larger footprint than JBoss. They set the default for Sun to 128 megabytes. On the other hand the JRocket JVM uses a different strategy that does not produce permspace OOMEs.

Final note. The following super-excellent toolkit will give you a precise picture of your permanent memory space and the other segments of the heap. I used this to determine our permspace exhaustion problem and compare WebLogic to JBoss footprints. The toolkit is super-excellent however the documenation is sub-optimal as this is an experimental tool. Check the FAQ on setting your JVM switches. Highly recommend this thing:

  • If you add -XX:+PrintClassHistogram to your VM option (if Sun) you can have a classHistogram what would help on finding where the memory was consumed. You can have that while getting a StackTrace

OutOfMemoryError: unable to create native thread

This error will occur even when you have plenty of heap, but the OS cannot allocate more memory for the threadstack.  You can reduce the size of the thread stack with -Xss128k (the default is 1mb on windows, ?? on linux).  The total memory usage equation is:

(heap size) + (number of threads)x(thread stack size) = (total RAM used by JVM process).

WARNING: JavaService has a bug that it will not allow you to change the thread stack size.

For more details, please refer to OutOfMemoryExceptionWhenCannotCreateThread.

References:

Obtaining Sun Heap Information (including how to debug and so on)

Sun jvmstat 3.0

Pete Freitag’s Performance Tuning Garbage Collection in Java

from http://www.andypemberton.com/jboss/compress-your-jboss-portal-theme-with-packtag/

The goal of this article is to show you how to use pack:tag to optimize the performance of your JBoss Portal theme. I’ve used this approach on a production JBoss Portal 2.6 implementation and tested the approach out in version 2.7.

JBoss Portal has a feature-rich theme framework where CSS and javascript resources are included in the Portal; building a custom theme is easy. Pack:tag is an open source project that optimizes performance for java-based web apps; it provides a JSP tag library that automatically minifies, compresses, and combines CSS and javascript resources.

As more rich features and dynamic components reach your portal, larger AJAX frameworks and CSS libraries are required to support them. Large downloads will not only make your Portal load slower, but will also take longer to execute when using the Portal. Also, Portals are no longer accessed solely inside the firewall, many companies use them to power external facing sites – so few assumptions should be made about client bandwidth. Compressing your Portal theme with pack:tag will lead to faster downloads and page response time.

Building a custom Portal theme is covered in depth elsewhere, so we won’t get into that here. Instead, let’s look at the steps necessary to get your theme working with pack:tag:

Install pack:tag

  • Place the packtag-X.X.jar in the WEB-INF lib of your theme. To use pack:tag with one of the out of the box themes, place the packtag JAR at: [PS_HOME]/server/default/deploy/jboss-portal.sar/portal-core.war/WEB-INF/lib
  • You’ll also want to place the packtag.properties file in WEB-INF

Pack Your Theme

  • By default, you should have theme resources defined in a *-themes.xml file – because pack:tag uses a tag library, we have to move these resources from the XML file and put them into your layout JSP page.
  • Add the pack:tag tld reference to your layout JSP:
    1. <%@ taglib prefix=“pack” uri=“http://packtag.sf.net” %>
  • Wrap the resource references in the pack:tag; for our custom theme this looks something like:
    1. <pack:style>
    2. <src>/styles/extjs/css/ext-all.css</src>
    3. <src>/styles/extjs/css/xtheme-gray.css</src>
    4. <src>/styles/app.css</src>
    5. </pack:style>
    1. <pack:script>
    2. <src>/scripts/jquery/jquery.js</src>
    3. <src>/scripts/extjs/adapter/jquery/ext-jquery-adapter.js</src>
    4. <src>/scripts/extjs/ext-all-debug.js</src>
    5. </pack:script>

Limitations and Gotchas

  • In JBoss Portal themes, layouts and themes are loosely coupled: layouts are used to generate markup, while themes include CSS and javascript references to style the layout. If you’ve written a JBoss Portal theme before, you’re probably thinking that we just tightly coupled the layout and theme.
  • Well, this is true – but, it turns out that the mechanism that provides the loose coupling has some problems out of the box. For one thing, Portal reorders your script and CSS references in the worst possible way (placing all the links after the scripts). This violates Yahoo’s best practices for website performance.
  • So, we can work around the tight coupling we’ve added by creating an additional JSP include file that will store the css/js references for your custom theme(s). You can then dynamically reference the active theme to load the appropriate theme files. The following snippet will do the trick for JBoss Portal 2.6.X:
    1. <jsp:include page=“includes/theme-${requestScope['RENDERCONTEXT'].themeContext.theme.themeInfo.name}.jsp” />
  • Additionally, introducing pack:tag can also cause unexpected issues with your theme. Because pack:tag combines all your resource requests into a single request (see the first Yahoo performance rule), image references in CSS files can break. So if you get 404s on resource requests after enabling pack:tag, you’ll know what to debug.

Example

Check out the following Firebug screen shots depicting the actual file size savings in our custom theme:

Custom Theme CSS Before pack:tag

Custom Theme CSS Before pack:tag

Custom Theme CSS After pack:tag

Custom Theme CSS After pack:tag

Custom Theme JS Before pack:tag

Custom Theme JS Before pack:tag

Custom Theme JS After pack:tag

Custom Theme JS After pack:tag

Results

That’s right! Adding pack:tag resulted in:

  • Total CSS file size downloaded went from 141KB to 21KB – ~15% the original size
  • 6 HTTP requests for CSS reduced to 2
  • Total javascript file size downloaded went from 2MB to 188KB – ~10% the original size
  • 21 HTTP requests for javascript reduced to 1

References and Tools

JBoss Properties

from JBoss Wiki

JBoss Properties

There are a number of properties used by the micro-kernel during the bootstrap.

This documentation is heavily plagiarized from

org.jboss.system.server.ServerConfig

.

Bootstrap Configuration

  • jboss.boot.library.list – The basic jars used to bootstrap the kernel, there are other jars used (TODO explain) – default value log4j-boot.jar, jboss-common.jar, jboss-system.jar
  • jboss.server.type – The fully qualified class name of the

    org.jboss.system.server.Server

    implementation – default

    org.jboss.system.server.ServerImpl

  • jboss.server.root.deployment.filename – The file to deploy at the end of the bootstrap, relative to the config url – default

    jboss-service.xml

Directories and urls

  • jboss.home.dir – The base directory of the jboss distribution – default

    $JBOSS_HOME

  • jboss.home.url – The base url of the jboss distribution – default

    $JBOSS_HOME

  • jboss.lib.url – The url where the kernel jars exist – default

    $jboss.home.url/lib

  • jboss.patch.url – A directory where patch jars exist – default

    none

  • jboss.server.name – The configuration name of the server – default

    default

  • jboss.server.base.dir – The directory where server configurations exist – default

    $jboss.home.dir/server

  • jboss.server.base.url – The url where server configurations exist – default

    $jboss.home.url/server

  • jboss.server.home.dir – The directory for the current configuration – default

    $jboss.server.base.dir/$jboss.server.name

  • jboss.server.home.url – The url for the current configuration – default

    $jboss.server.base.url/$jboss.server.name

  • jboss.server.temp.dir – The directory for temporary files – default

    $jboss.server.home.dir/tmp

  • jboss.server.data.dir – The directory for data files – default

    $jboss.server.home.dir/data

  • jboss.server.config.url – The url for configuration files – default

    $jboss.server.home.url/conf

  • jboss.server.lib.url – The url for static jar files – default

    $jboss.server.home.url/lib

  • jboss.server.log.dir – The directory where the server logs are written – default

    $jboss.server.home.dir/log

Other config

  • jboss.bind.address – The host name or ip address for jboss services to bind to – default

    0.0.0.0

    = “ANY” NIC – (v4.2.)

    127.0.0.1

    = localhost only

  • jboss.partition.name – The cluster partition – default DefaultPartition
  • jboss.partition.udpGroup – (since v4.0.3) The udp group – no default
  • jboss.server.exitonshutdown – Whether JBoss should do

    System.exit()

    on a shutdown – default true

  • jboss.server.blockingshutdown – Whether JBoss should do shutdown synchronously (true) or asynchronously (false) – default false
  • jboss.server.requirejbossurlstreamhandlerfactory – When true an error is thrown if the jboss stream handlers could not be installed – default true
  • jboss.server.temp.dir.overrideJavaTmpDir – (since v3.2.3) whether to override the main java temporary directory (java.io.tmpdir) to the server temporary directory – default false
  • jboss.shutdown.forceHalt – (since v3.0.1) force a Runtime.getRuntime().halt() at the end of the jboss shutdown hook – default true
  • jboss.native.load – whether to to load the native libraries unpacked from deployments – default false
  • jboss.native.dir – location to unpack native libraries in deployments – default tmp/native

Non JBoss properties

  • log4j.configuration – override the location of the log4j bootstrap configuration

Please refer to http://www.jboss.org/community/docs/DOC-12185

1. Configure the web application for security by adding constraints to the web deployment descriptor.

     <security-constraint>
          <web-resource-collection>
               <web-resource-name>All resources</web-resource-name>
               <description>Protects all resources</description>
               <url-pattern>/*</url-pattern>
          </web-resource-collection>
          <auth-constraint>
               <role-name>WebAppUser</role-name>
          </auth-constraint>
     </security-constraint>

     <security-role>
          <role-name>WebAppUser</role-name>
     </security-role>

     <login-config>
          <auth-method>BASIC</auth-method>
          <realm-name>Test Realm</realm-name>
     </login-config>

2. Configure the jboss-web.xml file to point to the “my-web” application.

<security-domain>java:/jaas/my-web</security-domain>

3. Configure the login-config.xml file.

    <application-policy name = "my-web">
		<authentication>
			<login-module
				code="org.jboss.security.auth.spi.UsersRolesLoginModule"
				flag = "required">
				<module-option
					name="usersProperties">
					props/my-web-users.properties
				</module-option>
				<module-option
					name="rolesProperties">
					props/my-web-roles.properties
				</module-option>
			</login-module>
		</authentication>
	</application-policy>
Powered by WordPress. Theme: Motion by 85ideas.