Recently in Portal Server Category

Howdy all.  After a long hiatus I'm back to blog your socks off with some technical minutiae that will save a few of you lots of headaches, and help the rest of you get a good night's sleep.

Long Story Short (i.e. "Just the useful info, please") 

There's a bug in the JDK that causes problems when setting up certain types of Java server socket constructs on some Solaris 10 boxes.  This bug will likely manifest itself in one of the following ways in your ALUI environment:

1)  You're running the ptlogging utility and see your logs filled up with something like:

PTSelectorThread_17679958      

com.plumtree.openkernel.impl.openhttp.core.network.PTSocketSelector     Unexpected exception.

java.io.IOException: Invalid argument

        at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)

        at sun.nio.ch.DevPollArrayWrapper.poll(Unknown Source)

        at sun.nio.ch.DevPollSelectorImpl.doSelect(Unknown Source)

        at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)

        at sun.nio.ch.SelectorImpl.select(Unknown Source)

        at sun.nio.ch.SelectorImpl.select(Unknown Source)

        at com.plumtree.openkernel.impl.openhttp.core.network.PTSocketSelector.run(PTSocketSelector.java:400)

        at java.lang.Thread.run(Unknown Source)

 

2) Portal starts up fine, but it can't connect to any remote servers, giving you the same stacktrace as above:

java.io.IOException: Invalid argument

        at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)

        at sun.nio.ch.DevPollArrayWrapper.poll(Unknown Source)

        at sun.nio.ch.DevPollSelectorImpl.doSelect(Unknown Source)

        at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)

        at sun.nio.ch.SelectorImpl.select(Unknown Source)

        at sun.nio.ch.SelectorImpl.select(Unknown Source)

        at com.plumtree.openkernel.impl.openhttp.core.network.PTSocketSelector.run(PTSocketSelector.java:400)

        at java.lang.Thread.run(Unknown Source)

So what's a good god-fearing person like yourself to do?  Well, if you act now, we'll send you TWO workarounds for the price of one:

1) Have an SA up the hard File Descriptor (FD) limit on the server to 8193 or greater by editing /etc/system to have the line:

set rlim_fd_max=8193

Note: You'll need to bounce the box after this change.  You can then verify it worked by running:

ulimit -n -H

Which should return a number >= 8193.  Sadly, this approach will probably have the SA asking you why you want to make the change, which means you'll have to read the technical details below....so onto option #2

2) Tell the appropriate JVMs to use a different Socket Selector configuration.  You do this by passing the following option to the JVM:

-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider

Depending on what ALUI component you're updating, you may pass this option in different ways.  For instance, if you're dealing with one of the back-end servers (Collab, Studio, etc), you'll want to update wrapper.conf to add additional arguments like:

wrapper.java.additional.7=-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider

Note: Replace "7" in the above line with the appropriate number for your wrapper file.

Or you may just need to update a shell script somewhere that's kicking off Tomcat/Weblogic/etc.  Note that these scripts all have their own Shell variables for holding additional Java arguments, so just look through them and update as appropriate.  If you have problems, feel free to post questions here and we'll do our best to help out.

Long Story Long (i.e. "I'm kind of a geek, and I'm sitting at work with nothing else to do, so give me the details")

So ALUI uses the NIO java packages that were introduced in Java 1.4.  FWIW, I always thought NIO stood for Non-blocking IO, but a little Googling reminds me that it's actually New IO...silly me.  In any case, the NIO packages let you do some cool things with sockets to more efficiently manage high-volume connections.  The under-lying problem you're running into is that out-of-the-box Selector implementation in the JDK uses /dev/poll to allocate 8192 File Descriptors (FD) for use by the selector, and 8192 exceeds the nofiles (Number of File Descriptors) limit on your server.  So, you can either bump up the server FD limit ala work-around #1 above, or tell Java to use a different selector implementation that doesn't allocate all those FDs ala option #2 above.  If you're interested in more detail, you can find the Sun bug on the issue here.

Until next time...thanks for reading! 

We just got back from OracleWorld last week, and wow!  That conference is unbelievably huge, but very well-organized.  We met a lot of current and past friends and colleagues out there, but a big part of our attendance was to get more insight into the future of the AquaLogic portal stack.

Once again, Oracle reaffirmed 9 years worth of support for the AquaLogic line, but their commitment to keeping Aqualogic as the primary code base wasn't as strongly expressed.  As you may know, Oracle has the WebCenter Suite - of which ALUI (WebCenter User Interaction), will play a part.  But Oracle's portal and BEA's portal will also remain in this space.  The current plan is to take most of the existing integration products and portals and fit them together in a more standards-based suite of producers (Oracle Services) and consumers (portal products), so you'll be able to leverage all of the cool new services that Oracle is working on with any of these portals.

They're also working on this thing called Oracle WebCenter Spaces, which is a fantastic-looking UI for creating "portals" with JDeveloper and Oracle's Application Developer Framework.  This thing was slick - we went to a lab where we created a rich mock-customer UI which integrated elements of Oracle's Content Management system (which'll replace Publisher) using JDeveloper and just dragging-and-dropping widgets onto a page and wiring the objects together with property pages.  The thing felt more like BEA's portal (which was more developer-focused) than AquaLogic's (more configuration than development), but it was still pretty impressive. 

We were told all of those rich components will be surfaced through the AquaLogic portal as well via WSRP, so in theory, ALUI customers aren't left out in the cold as these rich components are developed.  As Oracle fine-tunes the ultimate portal strategy, they're also developing these components as "WebCenter Services", which are basically standards-compliant portlets that will be available to all portals.  So we should be getting the best of all worlds - existing portals plus all the "generic" web services (like discussion groups/collab, and the new Enterprise 2.0 functionality). 

The big outstanding question, though, is whether WebCenter Spaces will become the de-facto "portal" that gets the most development effort from the Oracle Team on a go-forward basis.  Eventually these products will have to start consolidating, and time will tell whether that's nine years from now where each product has gradually started looking like the next anyway, or 2 years from now where more dramatic migration strategies will need to be put in place.  My take?  Either way, it's no big deal.  We Plumtree folks have had some pretty major upgrade/migrations to go through before, and we were always taken care of.  Remember how hard the 4.5WS -> 5.0 migration was?  Well, we haven't had a major game-changing upgrade since then (the 5 -> 6 upgrade was pretty clean, but was more evolutionary than revolutionary).  If Oracle does go with a big migration strategy from the ALUI code base to something else, I'd bet that the migration won't be as complicated as the 5.0 migration was, and the rich new set of functionality available will make it worthwhile.

The important thing here is:  don't panic!  ALUI will be around and recognizable for a LONG time, and judging by what we saw at OracleWorld, there are lots of exciting new technologies just around the corner that will make it even more valuable.

We've warned you before about ACL propagation when you're changing the security in ALI.  Heck, we even created a product to ease the pain of this important task.  Today's bug is about another issue with security propagation.

Well, it's actually 2 bugs (maybe 3).  Let me explain:

When you answer "yes" to that question about security propagation, a job is created.  Here's the problem:  the job is run as the user who created the folder, not the user changing the security.  What if you later delete that user?  Well, bug #1: automation server is hosed.  You're going to get an error like this:

The Exception says "*** Job Operation #1 of 1 with ClassID 20 and ObjectID 898 cannot be run, probably because the operation has been deleted.", and the error's wrong (because it says "probably", I won't count this as a bug).  The real problem in this case is that the folder's OWNER has been deleted, not the operation itself.

This gets me to Bug #2: when you delete a user, they're removed from all groups, but apparently they're not removed as OWNERS of any of the admin folder objects (and how could they?  What should they revert back to?).  Obviously, this is what causes the problem with automation server.  If this one was fixed somehow, bug #1 would become irrelevant.

Bug #3 (this one I haven't confirmed yet, but is likely to exist given the testing and logs mentioned above): suppose Joe Content Manager creates an entire structure of folders.  Then Joe's boss decides he shouldn't be an admin for one of the child folders (say, an "Executive Committee" folder) and removes his access.  He changes the security and propagates it on that "Executive Committee" folder.  Later, he wants to add Mary Executive to have privileges to the folder.  He changes the ACL again and chooses to propagate.  Here's the rub:  because the job is run as Joe, and Joe no longer has access, the job fails, and Mary can not be added.  In fact, it's likely that Joe can't even be added back, so that ACL is completely frozen unless the admin goes through every object and re-adds Joe back (or changes the owner of the folders through the DB).  Have I mentioned LockDown?

Anyway, want the SQL Scripts to fix the owners on the various folders?  Hit the jump.

This is a little old-school, but still a very relevant tip.  This problem has been around for all of the ALI 6.x days (including 6.5), and if I remember correctly, even the Plumtree 5.x days.  Basically, the automation server logs its activity to the PTJOBLOGS table, and if you've got jobs that are logging in verbose or very frequently, this table can become HUGE:  I had a recent customer whose database had grown to over 80 GB because of this table.

Basically, to prevent this table from growing astronomically big, make sure:

1. You don't have jobs that are running way too often (once a minute typically means a job is running - and logging - constantly)
2. You don't have verbose logging for any jobs running in the portal, and
3. That your portal configuration is set to only save a reasonable amount of job log data.  By default, the portal will keep around 60 days worth of logs, which is a pretty big number.  If you ask me, any job logs older than 7 days are worthless because jobs always run more than once a week.  But, of course, you're not asking me, so I'll just tell you how to change this setting and you can decide for yourself.  The configuration setting isn't available through the UI; instead you have to tweak the database.  Specifically, you have to update the PTSERVERCONFIG table in the ALI database with SETTINGID=15.  Set the value to whatever you think is appropriate based on your use of the job log:

Finally, what happens if you've already got a PTJOBLOGS table that contains 200 million rows?  Here's a tip that I got from our friend and client, Mike Jones at MedSolutions, Inc.: if you run an amateur update like "delete * from ptjoblogs", the update will take forever because all transactions will be logged.  If you run "truncate table ptjoblogs", on the other hand, you're just dropping the table and don't have to wait ridiculous amounts of time for the update to happen (not to mention the amount of database log space you'd be consuming).

When I first introduced the Configuration Manager, I wondered aloud how it would work in a multi-system environment.

Well, it turned out the the Configuration Manager isn't that complicated after all:  it's pretty much an interface for editing a configuration file on disk, so it does only apply to the system you're running it on.

The file can be found at bea\alui\settings\configuration.xml, and can be edited directly as easily as you would through the Configuration Manager interface (with the exception of passwords, which are encrypted):

I mentioned the ALI Interoperability Matrix (login required) in the Publisher 6.5 post, and realized that I don't always go to the official site to check compatible versions of the Aqualogic stack; instead I just use a locally saved copy because it's quicker to pull up. 

Obviously, the locally saved snapshot can get out of date over time, but it's nice to have when you need it in a pinch (having been on sites that don't allow you to connect to their network).

If you want an Excel copy of the matrix, you can download it here.  Keep in mind it's only current as of the end of August 2008, but for prior versions of the portal, the information should be pretty static. For the latest version, visit one.bea.com (while it lasts).

Experience Rules are a powerful way to provide different UIs based on certain conditions, such as the URL used by the portal, the client IP address, or the community a user is visiting.  But with this power comes some complexity:  occasionally rules don't work out the way you want, and you run into problems with getting the right rule to be applied at the right time.

This is where the Experience Rules Debug Messages can really come in handy.  To turn them on, you have to go to Administration: Select Utility... : Portal Settings.  There you'll see a checkbox to turn on the feature:

Once the feature has been activated, you have to turn it on for an individual user by going to My Account: Display Options: Advanced Settings:

... And once that's done, you'll see a link in the top bar of your navigation:

Click it, and you'll see a list of all the rules and which ones were applied based on the conditions specified:

But what if you have a custom navigation, and the link isn't available even after you turn on the settings in your configuration page?  The trick is to just know the URL that goes to the Experience Rules debug page: 

http://portal_server/portal/server.pt?open=space&name=RulesDebugMSGAS&page=RulesDebugMSGDP

Just log into the portal, and copy the link above into your browser.

At F1, we've done countless ALI installations and upgrades.  So many that, frankly, we sometimes get a little too comfortable with the upgrade process: install, run scripts, import PTEs (more on upgrade tips soon), and occasionally overlook things when they're first released.  Because the portal historically didn't come with PTE files, I occasionally forgot to import the search cluster PTE when upgrading to grid search back when 6.1 was released.

Now we're at 6.5 and I've found myself making the same omission: forgetting to import portal PTEs.  Specifically, 6.5 comes with a Remote Portlet Web Service, and it is used (among other things) to provide basic RSS functionality and Activity Stream functionality.  In order to get these objects into your portal, you need to import the RSS Content Types/Maps PTEs from \ptportal\6.5\serverpackages, and the portlet objects themselves from \remoteps\1.0\serverpackages.

The RSS reader provides some decent out of the box functionality, with a simple configuration screen:

... and a simple display of feeds:

Now for the product plug (not to be interpreted as ALI functionality bashing):  what if you want more feeds to work (I still don't know why our Function1 feed - http://rss.function1.com/AquaLogicBlog/ doesn't work with this portlet), history of all articles and not just ones that are on the feed at any given time, individual read status, and a preview pane?  Check out Function1's RSS Reader, of course.

As I've mentioned before, Adaptive Layouts are a great way to customize your UI.  But as they were first introduced in ALUI 6.5, there are still some rough edges to the technology.  Today's tips come from our friend Geoff Garcia at March of Dimes (interested in helping the cause?), and includes some downloadable layouts that you can use as a road map when customizing your portal.

Geoff starts with suggesting some links that we've had trouble finding too: The Adaptive Tag Documentation and The ALUI 6.5 Portal Documentation.

He then lists some tips and thoughts on layouts:

1. The stylesheets for the adaptive layouts are at: \ptimages\imageserver\plumtree\portal\private\css.
• I made a copy of the mainstyle.css to use with my customized adaptive layouts so as not to ruin the original.
• If you run into stylesheet problems don't forget to check the hardcoded quirks mode styles which are in the page layout code. They overwrite the mainstyle file some of the times.
2. The page layout files are at: \ptimages\imageserver\plumtree\portal\private\pagelayouts.
• I made a new folder and copied them all into that as the house for my "custom" layouts, again so I would avoid ruining the original.
3. There are minor inconsistencies between the search and KD page layouts both in the CSS and in the adaptive layouts.
4. The My Pages adaptive layout is only triggered when you either:
• Create a new My Page
• Change the layout of existing pages to use the new layout
5. The My Pages layout is super klunky
• The "advanced editor" is actually the old editor...hardly looks advanced relative to the slick fly-out editor!
• Columns no longer seem to matter, portlets take on a mind of their own depending upon which column you put them in and there doesn't seem to be very much rhyme or reason to the sizes they become.

Here's a screen shot of what he's accomplished:

If you'd like to see a couple more screen shots and the template files he used to create them, you can download them here.

Finally, check out his great post at http://forums.bea.com/thread.jspa?threadID=5700001804, which is mostly about how to make search/kd look closer to google with a few small tweaks.

So you know Dev2Dev blogs are being decommissioned, but there really is a treasure trove of information out there, and individual bloggers are scrambling to repost their articles elsewhere. Two of the top Plumtree/Aqualogic/ALI bloggers out there are Ross Brodbeck (new blog site here) and Fabien Sanglier (new RSS blog feed here), and a tip of the hat to our friends at BDG, who have gone on to "find other fun things to do with our time and money"; Chris Bucchere will no doubt have plenty of interesting content on his Ruby on Rails/Enterprise 2.0 blog.

Another prolific blogger back in the day before leaving Bea/Oracle was Ray Gao, who has given us permission to post more of his previous blog entries here. While I won't rehash all of his old articles in this blog, one in particular that stood out for me as a "neat trick" was his post on getting IE7's search bar to search your corporate portal.

Rather than reprinting his entire article, I'll just share the the steps he described:

1. Go to http://www.microsoft.com/windows/ie/searchguide/en-en/default.mspx?dcsref=http://runonce.msn.com/runonce2.aspx.
2. Enter http://<your_portal_server>/portal/server.pt?in_hi_space=SearchResult&in_hi_control=bannerstart&in_tx_query=TEST in box 3 on the right.
3. Enter a name for the search provider ("My Portal Search") and click "Install".
4. Confirm the security prompt and specify if you want this to be the default provider.
5. You should now see the new provider in the search bar!