Archive for the ‘Technical’ Category

Configuring JBoss server monitoring in ManageEngine AM

Wednesday, April 8th, 2009

Application Manager 8 have options to monitor various servers including JBoss server, but, for JBoss 5.0.1, I could not add a monitor easily. Telling long story in short, it is a 2 minute task if you have the correct way to do so (however I spent about a day to google for the solution and testing). So, here is the correct way:

  • Start JBoss server on a particular IP address by passing the “-b a.b.c.d” argument, where a.b.c.d is the IP address in dotted decimal notation, like 172.16.4.111 .

In Componence, we use a custom script to do that, i.e. runStandalone.sh or runCluster.sh; so, I updated that one.

  • Restart the JBoss server and try to add the monitor again, and it works.

But, you may not be able to monitor the JVM information yet. But don’t worry, this is also a 2 minute task to rectify the problem. Just

  • Copy the $APPMAN_HOME/working/resources/jbossagent.sar to the deploy directory of the running server so that it got hot deployed.

JVM information, max heap size and current heap size is now available.

Using XIP tool in WLP10.2

Saturday, March 14th, 2009

Installing the Export/Import Utility

You only need to perform the following procedure if you intend to run the Export/Import Utility as a stand-alone application. If you only want to run the WorkSpace Studio propagation tools, then the following procedure is unnecessary.

  1. Before installing the Export/Import Utility, be sure you have Ant 1.6.5 in your PATH environment variable. Ant is part of the normal WebLogic Server installation. It is located in:
  2. <BEA_HOME>/modules/org.apache.ant_1.6.5/bin

  3. Stop WebLogic Server if it is running.
  4. Open the file <WLP_HOME>/bin/xip/build.xml, and edit the following properties in the Installer section to point to the appropriate locations:
  5. Property
    Description
    bea.dir
    Points to <BEA_HOME>/wlserver_10.0.
    wlp.lib.dir
    Points to ${bea.dir}/portal/lib.
  6. Using a utility such as WinZip, open the following WAR file:
  7. <WLP_HOME>/lib/modules/wlp-propagation-web-lib.war

  8. Extract the file propagation.jar from the WAR file and save it in <WLP_HOME>/lib.
  9. Tip: If you place the propagation.jar file in <WLP_HOME>/lib, you do not need to add it to the wlp.classpath in the build.xml file. If it is not in this directory, you must add it to the wlp.classpath in build.xml.
  10. Create a directory called ejb under ${wlp.lib.dir}/netuix, and extract netuix.jar from the following EAR and place it in that directory:
  11. <WLP_HOME>/lib/modules/wlp-framework-full-app-lib.ear

    Note: The file ${wlp.lib.dir}/netuix/ejb/netuix.jar is referenced in the wlp.classpath in build.xml.
  12. Build the Export/Import Utility. To do this, run the following command from within the <WLP_HOME>/bin/xip directory:
      export JAVA_HOME=$BEA_HOME/jdk150_11
  13. ant

    Note: If you get the error “taskdef class weblogic.ant.taskdefs.build.LibClasspathTask cannot be found”, please provide additional lib reference to ant as -

    ant -lib $BEA_HOME/wlserver_10.0/server/lib/weblogic.jar

    Note: You may also get some error like “java.lang.UnsupportedClassVersionError: org/apache/tools/ant/loader/AntClassLoader2″, please also set variable JAVA_HOME to your jdk1.50_11 as -

    export JAVA_HOME=$BEA_HOME/jdk150_11

    Note:It is recomended to make a shell script with all the tasks required to run as:


    #!/bin/bash
    export BEA_HOME=/usr/bea/bea102
    export JAVA_HOME=$BEA_HOME/jdk150_11
    export WEBLOGIC_HOME=$BEA_HOME/wlserver_10.0
    export PATH=$PATH:$BEA_HOME/modules/org.apache.ant_1.6.5/bin
    export WL_HOME=$WEBLOGIC_HOME
    ant  -lib $BEA_HOME/wlserver_10.0/server/lib/weblogic.jar

    You may safely ignore the error <BEA-160144>

    Overview of the Export/Import Utility

    The XIP Utility allows a full round-trip development life cycle, where you can easily move portals and desktops between a WorkSpace Studio environment and a staging or production environment, as shown in figure:

    Round Trip Development

    Round Trip Development

    This utility lets you import .portal, .pinc, and other portal framework files into the database, and lets you export these files from the database. The exported files can be loaded back into WorkSpace Studio, or imported into another WebLogic Portal database.

    The utility performs its work in a single database transaction. If the utility fails for some reason, the database is not affected.

    What the Utility Moves

    The Export/Import Utility moves desktops, portlet references, books, pages, and localization definitions. In other words, the utility exports .portal, .pinc, and other portal framework files from a database, and imports the contents of those files back into a database.

    Note: The actual definitions for portlets, look and feels, shells, menus, layouts, themes, JSPs, and other code are contained in the EAR file. These files are stored in directories in portal web applications, such as the framework/markup directory. If any of these file-based elements change, you must rebuild and redeploy the EAR. The .portal and other portal framework files simply refer to the definition files.

    What the Utility Does Not Move

    The Export/Import Utility does not handle the following items: campaigns, behavior tracking events, content management assets, entitlements, WSRP producer registration, portlet categories, localization resources, user profiles, and commerce data.

    Refining Rules for Exporting and Importing

    The Export/Import Utility allows you to select an object (desktop, book or page) at any level (library, admin, visitor) and import it or export it, according to specified rules.

    To refine and customize the export and import of .portal, .pinc, and other portal framework files to and from the database, you can:

    * Specify rules to determine how portal elements are merged. For instance, in a manner similar to that of a source code control mechanism, changes in a .portal file can be merged with changes in the database.
    * Specify scoping rules. Scoping rules determine how new books and pages will be merged into the new environment. Note that user and administrator customizations are preserved when assets are merged.

    As shown in Figure below, the Export/Import Utility offers flexibility with respect to importing, exporting, and scoping. You can scope changes to the library, admin (desktop), or visitor (individual user) level. For instance, if you import a desktop at the admin scope, the imported changes will be applied only to the specified desktop. If a user has customized that particular desktop, then the changes will also be inherited by the user desktop. Note, however, that changes are never inherited up the hierarchy. Elements in the library will not inherit changes made to a desktop.
    Tip: For a more in depth discussion of the relationship between the library, desktops, and user views, see Scope and Library Inheritance.

    Options

    Options

Optimizing WebLogic Portal for search engines

Monday, December 8th, 2008

External or internal facing?

Something to take into consideration when starting up a customer facing portal is its SEO friendliness. For instance, WebLogic Portal generally has endless URLs with structures and characters that just don’t make sense to search engines. Though this might not be a problem for internal facing portals, it is a big problem for all external facing portals.

Lead generation
Search engines, like Yahoo or Google, are crucial to generating business on the internet. Without optimization your portal can easily miss out on 5 to 10 times the amount of visitors, and potential clients, who currently come through the search engines. Just imagine how much easier it would be to defend your online marketing / investment budgets, if the amount of visitors were to double or triple?

Search Engine Optimization Portlet
At Componence we have years of hands on experience in solving this problem for a lot of publishing and online information business. Our special Search Engine Optimization (SEO) portlet offers a diverse range of features that will allow you to manage your portal’s behavior and visibility in search engines:

 

  • Automating the meta data generation (title, keywords, description) from specific portlet pages;
  • Using taxonomy data to be used as meta data;
  • Allowing you to manage your own search engine friendly URLs that are more relevant;
  • Allowing you to manage and generate the site maps for Google or Yahoo;
  • Allowing you to manage the proper content and redirection for error pages;

You can download our special whitepaper for our SEO portlet solution hereseo_portlet

Continuous pursuit to optimize Weblogic Portal performance

Saturday, November 1st, 2008

At Componence we have been specializing in Weblogic Portal development for over 3 years now. The possibilities to integrate different systems / applications / services are really fenomenal, but the biggest pain for any portal platform is eventually the performance. Beside our own experiences within our Portletsuite development team, I heard the same from many developers / architects from all over the world; throughput can be 1-5 pages per second … (these numbers have been seen in single CPU to clustered environments up to 16 CPU’s).

Some related articles about performance issues with Weblogic Portal:

It’s about the portal size & amount of portlets used
Because of the structure of the portal and the used pageflow model the performance of the portal will drop substantially as the amount pages & portlets used increases. BEA even advises not to make portals bigger than 300 pages, because beyond that the portal will break at certain points. With the ease of use, accidently one of our customers made a portal by themselves with about 800 pages. I’m not sure if it’s Portletsuite, but the portal has been running quite stable for the last few months.

The big difference with regular web applications is the fact that a portal can run multiple applications at the same time on the same page. And each application can consist of multiple pages within it. And often each application can carry their own preferences set for it’s users. So compared with regular web front-end technologies Java Portals can create a lot more requests / threads, depending on the different portlet / applcations that is used on a page.

The Enterprise Java portal platforms have tried to tackle this by offering multi-threaded (simultaneous) portlet rendering. IBM and Oracle surely have it in their framework. But most open source portals do not offer it. This is probably the reason why Liferay portals can have issues with their performance. The Liferay standard portletset uses a lot of AJAX for asynchronous rendering to tackle these issues, but many customized portlets might not be. But I have heard that the open source Jetspeed portal does support this.

Portletsuite performance track gives hope
When we launched Portletsuite 1.0 three years ago for BEA Weblogic Portal 8.1 we had difficulties understanding the performance issues the portal framework brought along. I can remember medium portals had a throughput of 1-2 pages/second. Of course when compared with more regular web front-end frameworks this is a disaster. But it was just a fact and we had to deal with it.

After working together with BEA consultants, our PS 1.3 version released for Weblogic Portal 9.2 last year could handle a throughput of 7-10 pages/second. We had to change the architecture of our portlets to be better equipped to work better with the tree optimizer of the WLP framework and different caching possibilities.

With version 1.5 released in March last year, our performance again increased while we added many more new features to our standard Web 2.0 / WCM portlet set! With just the standard portlets in Portletsuite 1.5 a medium portal will generate a throughput of 17-20 pages/second.

Win the battle outside of the portal!
While most developers, IT managers, architects are focussing on how to improve the performance of the portal, the battle can be won elsewhere. Fixing internal portal performance issues will only have 10-20% effect on the user experience. The following 2 areas related to the webserver & browser cache will give greater results for the users:

  • Decrease unnecessary browser requests & download
    The best wins are gained in the browser! Nowadays pages are typically > 500KB big and require >50 HTTP requests to build up their site. The browser takes a lot of time to retrieve these resources and to build up the page, easily taking 5-10 seconds. By making sure that each resource has an expiry date in it’s headers, this way many re-occuring resources do not need to be downloaded. This will easily decrease the amount of HTTP requests to 2-5 when visitors come back to the portal. The result will be that the browser will need easily 50% less time to build up the page. This fix will not have a substantial effect on the throughput.
  • Make entry pages cacheable
    In customer facing portals, many entry pages will have content. Content is not always static, but can easily handle a delay of 5 minutes. If you can cache up to 10 pages that are responsible for 20-30% of the pageviews, then chances are that the throughput can easily be increased with 10 times . And the average response time will drop dramatically. This is what we have proven in a portal that we have built. After turning on the page cache, only for anonymous users, the reports shows that the average response time dropped easily below 1 second .

Page cache for the homepage was good enough to stabilize this portal

Portal page caching with Portletsuite
The portal page cache solution, that is available in Portletsuite 1.6, was merged in this portal that was based on Portletsuite 1.4. The portal page caching solution enables portal administrators to easily select / deselect the pages that need to be cached in the virtual memory. With this solution I’m quite sure many Weblogic Portal clients can easily increase their ROI, as Enterprise portal investments are usually huge. I’m quite happy that in Portletsuiet 1.7 we will also enable caching for users with entitlements and preferences.

And just to think that many colleagues and clients were scrutinizing this solution of Abhay, one of our most talented colleagues in Jaipur, almost causing him to stop this line of development … Thank you Abhay!