Bug Blog 9: WebCenter Analytics Timeouts

In our last post, we touched on the unusual nature of BEA’s acquisition of Plumtree, and how BEA largely kept the portal product lines separate with ALUI and WLP.  But that’s not a completely fair assertion: BEA did have a longer-term goal, integrating the two portal “front-ends” through various back-end tricks (such as Ensemble and WSRP).  Similarly, while you may have read that post as a somewhat bleak assessment that my opinion is WCI is dying a slow, painful death, in reality Oracle has stated plans to provide integration services between the products through similar means.  So you could use a WCI front-end with integration through Ensemble and WSRP to other WebCenter Services such as Blogs and Wikis.

The reality, though, is that these types integrations take time – and sometimes, lots of it.  As evidence of this, look no further than Aqualogic Analytics.  When BEA acquired Plumtree, one of the gaping holes in WLP was Analytics, or usage reporting of the product.  Plumtree Analytics was becoming a solid product, but it was very tightly integrated into the Plumtree portal.  So the decision was made to try and abstract some of the major pieces out, with the thinking that these abstractions could be useful elsewhere.  For example, the ill-fated Security Services (once used by the also ill-fated PEP line and now just built into Analytics) and the existing Directory Services came of this integration attempt.  The idea was that by abstracting out security and user management:

  1. These services would be available to other applications that were developed down the line
  2. Analytics would be more compatible with WebLogic Portal, which also had an LDAP repository to access user and group information

While I think that if more time had been available for the integration to become more seamless, the problem is that no one won in this attempt because it was aborted too early.  I have no idea whether WLP still supports Analytics integration, the old Security Services are now just built into the product as a phenomenally complicated set of DB tables that make little sense, and Directory Services are a dramatically inefficient way to access user and group information.

Case in point – I’ve had a couple of clients report Analytics timeouts for some users, but other users were seeing the proper report:

How does this relate to the whole Plumtree/BEA/Oracle integration saga? The old Plumtree Analytics application used a SQL query called something like QUERY_USER_FLATTENED_GROUPS.  Basically, this was a Plumtree Portal-specific SQL query that, given a user ID, would spit out all nested groups that that user was a member of.  So if a user was a member group A, and Group A was a member of Group B, the query would return both Group A and B.

The ALUI version of Analytics, though, utilized Directory Services so that group membership didn’t need to come from PT-specific SQL queries.  It could come from generic LDAP queries.  The problem is, LDAP doesn’t have a mechanism like QUERY_USER_FLATTENED_GROUPS, so for any given user, Analytics needs to query LDAP for the groups a user is in.  And then, Analytics needs to check to see which groups THOSE groups are a member of.  And so on, and so on.  You’d be surprised – through inheritance, you may be a member of thousands of groups, and rather than a single SQL query, you’re now dealing with tens of thousands of LDAP calls.

Bottom line:  Integrations and product convergence can work, but they’re phenomenally complicated, because every piece of abstraction added can cause unanticipated side effects.  Which is probably why Oracle is taking this whole process pretty slowly.

Full Bug Report after the break for your convenience.

Hdr: 9589635 20.05 PERF GEN PRODID-5388 PORTID-46

*** 04/15/10 03:33 pm ***

  Product: Oracle WebCenter Analytics (5388)
  Problem Description
  The WebCenter Analytics Console community in the WebCenter Interaction
  portal loads slowly or experiences a timeout when the user accessing the
  product is a member of many portal groups, especially if membership is
  gained through nested groups-in-groups. For example, a user with less than
  200 group memberships loads Analytics in 7 seconds while a user with
  more than 1000 direct group memberships loads Analytics in 84 seconds and
  a user with more than 1000 group memberships through nested
  loads Analytics in 136 seconds. By contrast, all three users can load a
  simple WCI community in a few seconds.

  Steps to reproduce
  1. Create a WCI user with access to Analytics but only grant them
     membership in a few groups.
  2. Create a WCI user with access to Analytics and grant them membership in
     more than 1000 groups directly with no groups-in-groups.
  3. Create a WCI user with access to Analytics and grant them membership in
     in nested groups-in-groups that yield membership in more than 1000
  4. Test loading Analytics console with each user.
  5. Test loading a simple WCI community with each user.

  Expected Behavior
  The time to verify activity rights to Analytics should be similar to checks
  for other portal resources.

  Increase the portlet timeout in the Analytics webservices in WCI portal
  Consolidate groups to reduce the number of total memberships per user.
  Reduce groups-in-groups nesting.

  Stack Trace or Diagnostic Data
  ===========    �
  Portal spy logs will show a long pause while at the same time Analytics
  Security spy logs many LDAP requests and ALUI Directory spy logs thousands
  of database queries.
*** 04/15/10 03:35 pm ***
*** 04/16/10 01:53 pm ***
Documented in My Oracle Support Knowledge Base Note 979305.1
*** 04/19/10 12:44 pm *** (CHG: Asg->NEW OWNER OWNER)

Tags: , ,

Leave a Reply