View feed: JBoss Portal
Navigation
Posts of this feed on this page
- Scaling JBoss Portal to a new height
- Developing portlets with the JBoss Portlet Bridge
- Portlet coordination
- JBoss Portal 2.7.0.CR1 is hot and available !
- How to monitor portal session data and replication?
- JBoss Portlet support in Eclipse
- Lurking at Hypersonic data
- Julien Viet's Blog
- Developing Portlets using JSF, Ajax, and Seam (Part 1 of 3)
- JBoss Portal and EPP releases
- (to view more posts, click the next/previous link)
Recent posts from all feeds
- esbgen: An easy way to create JBoss ESB Projects
- IBM Websphere - officially better than anything, ever
- Book review and NHibernate Search
- Red Hat Launches New JBoss SOA Assessment Tool
- Thank you !
- Jbpm Mail delivery
- JBoss Marshalling Framework 1.0.0.Beta1 Released
- Performance Comparison between NIO Frameworks
- Mobicents Metamorphosis
- JBoss Jbpm superstates
Scaling JBoss Portal to a new height
You may have guessed from previous blog that this was coming and it has. We have been working a lot on improving the performance and scalability (horizontal) of JBoss Portal lately and I am glad to tell you that it's scaling really well. Don't get me wrong, it was never too bad to begin with but there are always rooms for improvement. :-) JBoss Portal uses Hibernate for database related work and JBoss Cache for clustering and having both development teams in-house helped significantly as well.
Besides tuning our hibernate configurations and several code optimizations which improved the performance of a stand alone JBoss Portal server, our scalability exercise resulted into a new JBoss Cache and Hibernate integration library, the details of which you can find at this blog.. Without further ado, here is the result.
As you can see, scalability is linear (positive) going from a 1-node to 10-node cluster which is the best you can expect. What this means is that once you optimize your portal deployment on a single node, JBoss Portal server will not incur too much extra overhead when you deploy your application in a cluster. I would like to mention though that going from a 1-node to a 2-node cluster scalability is 85% which still is pretty good in my opinion. Now some testing details.For our testing, we used JBoss Enternprise Application Platform (EAP) version 4.3 production configuration because it has some OOB optimizations that we needed. We used a portal application which would test the core of portal server which meant an application that would follow the most common code execution path. It tested most commonly used interceptors, security layer, database access layer and portal management layer. We also made sure that fail over was happening correctly because in most use cases scalability without fail over does not mean much in a clustered setup. Load was increased until average response time remained less than 2 seconds with average think time of 1.5 seconds between requests.
All portal servers were deployed on RHEL4 servers on the same subnet. We used SmartFrog components to manage distributed deployment and testing. Requests were generated using our in house load generator as well as Grinder which hit the cluster fronted by apache load balancer. MySql5 was used as back end database. We did not tune MySql5 any more than what is commonly recommended for production setup. Performance tests and scalability tests are now part of continuous integration which is done using Hudson and its Smartfrog plugin that JBoss QA team has developed.
Many thanks go to Brian Stansberry, clustering lead and Galder Zamarreno, senior support engineer for not only creating the new JBC/Hib library but also for having patience to ruminate through many thread dumps.
We certainly had lots of fun with this exercise. Please let us know how it performs and scales in your deployment. These optimizations will be available from next release of JBoss Portal which are 2.6.7.GA (JSR-168 compliant) and JBoss Portal 2.7.0.GA (JSR-286 compliant).
Developing portlets with the JBoss Portlet Bridge
To celebrate the latest Beta 4 release of the JBoss Portlet Bridge, I have written the final article in the three part series titled "Developing Portlets using JSF, Ajax, and Seam" published on infoq.com.I tried to write each article in a easy to understand, get straight-to-the-point approach. The tutorials use maven archetypes and cargo configurations that allow all readers, novice or expert, to get up and running without having to worry about *any* configurations or reading further documentation. My focus was strictly for the user to input only two or three commands and have everything working without needing to cross reference a user guide or post any questions on the forums while working through the tutorials. Hopefully that will be your situation ;-)
All 3 articles can be found on the infoq site via the following links:
- http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-1
- http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-2
- http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-3
To learn more about the JBoss Portlet Bridge visit the project page.
Portlet coordination
Portlet coordination is a new set of features brought by the Portlet 2.0 specification (aka JSR-286).You can now define what is called "Public (or shared) render parameters" and events. The specification only defines the portlet *container* and not how portlets behave in a portal. It is up to the portal vendor to define how those shared render parameters and events will be bound.
In JBoss Portal we treat Shared render parameters in a similar way as events. We named "Event wiring" a link between an event to publish and an event to consume and "Parameter binding" the link between parameters. An event and a shared parameters are defined by a qualified name in a portal.
Implicit coordination
The most natural way it to bind (or wire) shared parameters (or events) that defined the same qname on the same page. This is the default behavior in JBoss Portal, and we call that "implicit binding" (or "implicit wiring" for events).
Here is a schema to understand, the portlets 1, 2, 3 define a render parameter called "urn:other:zip" while the portlet 4, 5, 6 define a render parameter called "urn:jboss:zipcode".
With the default behavior "implicit binding" any portlet modifying or accessing a render parameter with share the same value
Explicit coordinationThis is a natural and common use case, but there are time when you don't want that behavior, let's say you don't want them to share the same value and somehow want to isolate all those windows. You can turn off the implicit binding by either modifying the *-object.xml descriptor or through the GUI.
<portal>Here we turned off the implicit binding and kept the implicit wiring.
...
<coordination>
<bindings>
<implicit-mode>FALSE<implicit-mode>
<bindings>
<wirings>
<implicit-mode>TRUE<implicit-mode>
<wirings>
<coordination>
<portal>
Now all our windows have their public render parameters isolated.
Now we may want something in the middle, not all magically bound, neither all separated, even better, we bought the portlet represented in blue that has a shared render parameter which also represent a zipcode like ours. We do not want to make modification to that acquisition we simply want to tell the portal that we want to bind the zipcodes of windows 1 4 and 5. On top of that we want to bind 2 and 3. This can also be done wither through the descriptor file or though the admin portlet.
We now have the following scenario, without changing any code.
Voila ! We now have a way to "explicitely" define how shared render parameters are bound and it works in a similar way for event wiring.
Of course a nice addition to this would be the possibility to transform a render parameter or event payload on the fly (say the portlet you bought defines an render parameter string that represents an address, the format will probably be slightly different from the one you made yourself, we would need a class in between to do the transformation back and forth). We'll see how this feature get popular and how we can put that in the roadmap, but contributions are always welcome :)
Aliases
Last but not least we've also added the notion of aliases for render parameters. Say you have the two shared render parameters "urn:jboss:zipcode" and "urn:other:zip", you know they are similar (it's just a string that contains a zipcode), you can group them in an alias. That alias name can be used to pass a value as a request parameter of the portal.
You can define the alias in the object descriptor or through the admin portlet, in the XML it would look like:
<coordination>
<bindings>
<alias-binding>
<id>myzip</id>
<qname>{urn:jboss}zipcode</qname>
<qname>{urn:other}zip</qname>
</alias-binding>
</bindings>
</coordination>
Now by passing a request parameter to the page, the windows will get an initial value equals to the parameter you passed. Say your page URL is http://www.jboss-portal.org/portal/myPage you can pass a render parameters to your portlets by querying: http://www.jboss-portal.org/portal/myPage?myzip=20878, it's also what we call a page parameter.
I hope that I was able to give a not too long overview of implicit/explicit coordination, more details are available in the reference guide.
JBoss Portal 2.7.0.CR1 is hot and available !
I am really happy to announce the release of JBoss Portal 2.7.0.CR1.Here is what happened since the Beta1 on top of bug fixes:
We have been able to include in this release the new JBoss Portlet Bridge Beta 4 and an important upgrade of JackRabbit.
Also we have been able to considerably improve on the scalability of JBoss Portal by working on the JBoss Cache//Hibernate integration. Thanks a zillion to Brian, Galder (Who will soon blog about the technical details, we'll give you the link when ready) and Prabhat.
JBoss Portal 2.6.7 will also benefit from this improvement. We plan to blog with Prabhat on our latest results.
We added a GUI to manage the coordination between portlets.
Download is available from here if you are in a hurry, just grab the bundle, unzip it and start bin/run.sh or bin/run.bat then go to http://localhost:8080/portal as usual.
Thanks a lot and please report any issue in the forum, or even better contribute some code, some graphics, some translation, some doc... (By the way, thanks a lot to Matt Cook for his articles on Knol)
How to monitor portal session data and replication?
Lately we have been working a lot on improving JBoss Portal's performance and scalability. In this blog, I want to talk about how you can inspect what's in your session and how much data is getting replicated when a request is made to your portal deployment.You can not get hold of HttpSession object in your portlet. To get hold of HttpSession object, either you write your custom interceptor or a filter. What you have is access to PortletSession object through getPortletSession method of request object where request could be a RenderRequest or ActionRequest. Unfortunately, there is no session.getSize() method which would tell you how big exactly your portlet session is. You would have to enumerate through attributes in session in both PORTLET_SCOPE and APPLICATION_SCOPE, get their values then obtain their size as follow:
Enumeration portletAttribs = session.getAttributeNames();
Enumeration applicationAttribs = session.getAttributeNames(PortletSession.APPLICATION_SCOPE);
ByteArrayOutputStream bs = new ByteArrayOutputStream();
ObjectOutputStream os = new ObjectOutputStream(bs);
while(portletAttribs.hasMoreElements())
{
Object obj = session.getAttribute(portletAttribs.nextElement());
os.writeObject(obj);
}
Similarly you enumerate through attributes in applicationAttribs and add write them to ObjectOuputStream. Then you get the size using:
System.out.println("PortletSession Size is " + bs.size());The value you get is a close approximation to how big your portlet session is. HttpSession size will be bigger because portal needs to store the navigational state of your portlet/s as well.
Now, let's talk about how much data is getting replicated across your portal cluster. We will find this using JGroups MBean and JConsole which is the Java Monitoring and Management Console graphical tool shipped in J2SE JDK 5.0 and up.
First we need to prep up JBoss so that mbeans are available to JConsole. You can find the details at
JBoss-JConsole wiki. In a nutshell, you need to modiify $JBOSS_HOME/bin/run.conf. Your JAVA_OPTS should look more or less like
JAVA_OPTS="-Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dcom.sun.management.jmxremote -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanSe
rverBuilderImpl -Djboss.platform.mbeanserver"
Start JBoss Portal + JBoss AS bundle. In a separate terminal launch jconsole. You should automatically pick up PID of JBoss instance as shown here. Click Connect.
Now under MBeans tag, select Tree->jboss.jgroups -> protocol->Tomcat-Cluster->UDP as shown below. Here you will see total number of bytes sent and received by a node in cluster.
These Bytes Sent and Received value are for data related to session replication. To see replication data related to the second level cache used by Hibernate in Portal, you need to select
Tree->jboss.jgroups -> protocol->portal.hibernate->UDP
With those tools, you can now make sure that your sessions are not getting too large for the costly session replication on a cluster. You can use and abuse.
JBoss Portlet support in Eclipse
JBoss Tools 3.0.0 Alpha1 has been released with initial support for portlets (including JSF and Seam portlets).Two warning, first it is Alpha with all it means. Second one, the blog entry looks long and complicated. In fact i included many screenshots so that people who don't want to try can have a good overview of how it works. It's very simple for anyone a bit familiar with Eclipse.
First we need Eclipse Ganymede, JBoss Tools 3.0.0 Alpha1 and a version of JBoss Portal (bundle if you are looking for simplicity, and 2.7 if you want a Portlet 2.0).
Extract Eclipse and JBoss Tools, you should get a unique "eclipse" directory.
Extract JBoss Portal
$ tar zxvf ~/Download/eclipse-jee-ganymede-linux-gtk.tar.gz
$ unzip ~/Download/JBossTools-3.0.0.Alpha1-ALL-linux-gtk.zip
$ unzip ~/Download/jboss-portal-2.7.0.B1-bundled.zip
Now you should have an "eclipse" directory. Let's go in it and start Eclipse.
Once started go to the workbench and do File>New>Dynamic Web Project.
You can fill-in the name for your project.
And create a new "Target Runtime" such as on the following screenshot:
And point it to the location of your JBoss AS + Portal installation:
Now don't forget to set a Portlet Project configuration (Portlet 1.0 or 2.0)
And click on Finish.
Our base project is done, now let's add a portet into it.
Choose File>New>Other (or Ctrl+N) then select one of the JBoss Web Tools>Portlet wizard.
We'll pick Java Portlet for this blog. Fill in the Java Package and the class name and click Next.
On this other screen you will be able to set the display name of the portlet, a title, a description, the supported modes and init parameters.
On the next screen you can define which methods you want to override from GenericPortlet.
The last screen let you build JBoss Portal specific descriptors to create an instance during the deployment and place it directly on the portal.
Now that it is done, all the requires files are part of the Eclipse explorer and are ready to be built and deployed.
Now right click on the project and do Run As>Run On Server and accept the default. It will deploy the portlet web application and start JBoss AS.
(Little glitch, once started it will open the browser on http://localhost:8080/foobar, use http://localhost:8080/portal and you will see your portlet:
And voila ! From here you have access to all the other features of JBoss Tools.
Thanks Snjezana for the hard work !
Lurking at Hypersonic data
There are times when you want to look at your database data during development.It is also very common to keep using Hypersonic as a database during that same phase.
But do you know how to look at your JBoss Portal data ? Here is an entry-level explanation on how to do it. I got the idea of this blog entry by reading a question on a forum and hope it could help.
JBoss AS includes the "HSQL Database Manager" a GUI to execute SQL request on a HSQL server. To access it, you will need to go through the JMX console and locate the startDatabaseManager() operation on the jboss:database=localDB,service=Hypersonic MBean.
Clicking on "Invoke" should open up a new application that looks like this:
You see the content of the default datasource of JBoss AS. Now to see the default datasource of JBoss Portal click on File>Connect... You will see the following screen (after enlarging the window horizontally):
In the URL just change the final part: /data/hypersonic/localDB to /data/portal/hypersonic/database then click Ok.Voila, you can now browse the default JBoss Portal database and do SQL queries on it:
Note: If you wish to restart from fresh with default data, you simply need to delete the files from: server/default/data/portal and restart JBoss AS.
Julien Viet's Blog
I just want to signal people reading the JBoss Portal developer's blog that I just opened my official blog. I will share with you topics like portal, portlet, java, lot of cool stuff and my rants.Developing Portlets using JSF, Ajax, and Seam (Part 1 of 3)
InfoQ just published the first in a series of 3 articles for the JBoss Portlet Bridge.This one is about basic JSF development with an easy to follow tutorial and real world development tips. The next one will be about RichFaces and the final (about Seam) will be published right after the release of Beta 4 in early September.
Enjoy!
http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-1
JBoss Portal and EPP releases
We are very happy to announce the releases of JBoss Portal 2.6.6 and JBoss Portal 2.7.0.Beta1 !JBoss Portal 2.6.6 is a maintenance release, it also includes a lot of internationalization work done by Luca Stancapiano (with Italian translation) and partial Russian translation offered by Anton Borisow, thanks ! It's available here for community and will be accessible next week on the Customer Support Portal for our customers.
Now, probably even more exciting is the release of JBoss Portal 2.7.0 Beta 1. It now includes what we call "explicit coordination", we'll have to blog about that feature but there is already a Wiki and samples available out of the box. Also the new documentation is now available.
Now a bit more details about what will happen next:
The following scenario is what should happen:
- JBoss Portal 2.7.0 Candidate for Release 1 at the end of August
- JBoss Portal 2.7.0 General Availability in September
Of course all those dates are not written in stone and depend a lot on issues that we may discover and reported by users. Please try those versions as soon as they are out so we all don't have to wait ten more weeks for bug fixes (see below).
JBoss Portal 2.6.x and JBoss Portal 2.7.x community releases
All minors versions happen on a time-boxed release schedule. Every 10 to 12 weeks roughly, a new minor release comes out containing bug fixes and eventually new features. There is no change here, this is what has been already rolling out for the few past releases.
Community vs Enterprise Portal Platform
By December, we will release an Enterprise Portal Platform based on JBoss Portal 2.7.x and the Enterprise Application Platform 4.3.
What does it mean ? It means that our customers will have access to a JBoss Portal + EAP release with a fixed set of production ready features to guarantee the best stability. This set will be supported for up to five years with certified cumulative patches available. In the meantime, customers are still recommended to use the supported JBoss Portal 2.6 releases from the Customer Support Portal along with a version of the Enterprise Application Platform as the community versions downloaded from jboss.org are not supported. More details are available here. Feel free to contact me (thomas.heute@jboss.com) if you have any question about the supported products.
JBoss Portal 2.6 will be supported till September 2009, see here for details. JBoss Portal 2.4 full supports ends next month (August 2008) with an additional year for security errata and mission critical bug fixes only.
I will come back on the Enterprise Portal Platform details as we get closer to the release date.
I hope I answered the questions about our releases time-frames.
Now on a personal note, I'm getting two weeks off and will be glad to see my Normandy again :)