Adding Problem 3 for “23.2.1 Portlet Displays a Portlet Consumer Error”

Scott S NelsonLeave a comment

The Troubleshooting Oracle WebCenter Portlets documentation lists two problems under the Portlet Displays a Remote Portlet Communication Error section. Both seem legitimate causes and solutions, and I have run across both of them in the past. I hit a new one this week. Number three is running out of available threads in the Managed Server that is handling the request. This one was fun to find, because OOM errors that do not cause the server to fall over eventually clear up, and with an adequately sized cluster (the memory errors were caused by a dependent service failing) the issue is very random.

The symptom to look for is the OOM error in the log, which looks like this:

oracle.portlet.client.container.PortletException: java.lang.OutOfMemoryError: 
unable to create new native thread
	at oracle.portlet.client.tech.common.PortletFutureUtils.get(Portlet
FutureUtils.java:72)
	at oracle.portlet.client.tech.common.PortletSessionManager$InitSession
CompletionListener.conditionChange(PortletSessionManager.java:340)
	at oracle.portlet.client.service.pipeline.FutureConditionTask.done
(FutureConditionTask.java:168)
	at java.util.concurrent.FutureTask$Sync.innerSetException(Future
Task.java:273)
	at java.util.concurrent.FutureTask.setException(FutureTask.java:125)

Restarting the servers will give you temporary relief, though for the long-run you need to find the root cause. In this case, it was an undersized WebCenter Content cluster running on the same physical box sucking all the resources down. A larger cluster and load balancing corrected the issue for good (knock wood).

If you found this interesting, please share.

© Scott S. Nelson

Leveling the Playing Field

Scott S NelsonLeave a comment

(semi-continuation of A Tale of Two Migrations)

Before I get into the trials and tribulations of dealing with the inevitable custom implementations that are part of every WebLogic Portal application that is older than a year and has more than 5 pages (and there are newer, smaller apps with more customizations, trust me on that), it is best to look at some basics. In the path taken by this blog series we are using WSRP with the retiring WebLogic Portal (WLP) application as the producer and WebCenter Portal (WCP) as the migration target and WSRP consumer. It is definitely of value to review the standard documentation about how to configure this standards-based integration, which can be found for 10.3.6 at http://docs.oracle.com/cd/E41236_01/wlp.1036/e14235/chap_webcenter_interop.htm/ .

With all of the useful points provided in the documentation, the one point that I would like to add is to first start with upgrading your WebLogic Portal application and environment to the latest version. I am a strong proponent of not upgrading unless there is a clear value in doing so, and in this case there are several. One is that a migration from WLP to WCP is almost definitely going to require at least one (and most likely several) Oracle Support cases to complete. You will hear every time you open a case “please upgrade to the latest version”. I’m not a big fan of this approach, but since the goal of the project is to move everything to the WebCenter and all of the functionality will eventually need to be updated to the latest version as part of that process, it is worthwhile to get that out of the way now.

Another value of upgrading your WebLogic Portal before embarking on a staged migration is that with one of the release of WebLogic Portal 10.3.x from .2 or later (I didn’t know the specific version, am too lazy to go look it up, and don’t feel bad about that because it is moot at this point in time) and the corresponding WebCenter Portal release (see previous parenthetical comment) the WSRP engine was moved from the portal framework to the application server (WebLogic Server). This makes a great deal of sense since WebLogic Server has had a WSRP engine for quite some time (again, not doing the historical research for the curious). Since the underlying WSRP support is coming from the application server, it makes good sense to have the same engine on both sides of the tractor-pull known as WSRP. While it may not be entirely necessary between some versions (I strongly suspect –but have no proof- that this is the case between 10.3.5 and 10.3.6), it eliminates one point in the long chain that will eventually be examined in detail for the source of some unexpected result or other, so why not get it out of the way now?

Finally, WebLogic Server is still the gold standard of J2EE application servers and does continuously improve with each release (disclaimer: I have not worked with the 12c versions and am just hoping that they have not proven me wrong). So why not start off with the best foundation possible before dealing with the known risk of every migration which is that there will be unknown and unforeseen issues that arise.

In my case I pushed for the WebLogic Portal and Server upgrade to 10.3.6 because WebCenter 11.1.1.8 had just been released with its capability of including the MAR within the EAR, a major time and hassle saver. WebCenter 11.1.1.8 was release with no support for WebLogic Server 10.3.5, which explains the “coincidence” of WebLogic Portal 10.3.6 coming out two weeks before hand. Interestingly enough, development on WCP 11.1.1.8 is done with JDeveloper 11.1.1.7 which is only configured to work with WebLogic Server 10.3.5. Ah, if Fox Mulder were only a software engineer instead of an FBI agent 😉

If you found this interesting, please share.

© Scott S. Nelson

A Tale of Two Migrations

Scott S NelsonLeave a comment

My first portal migration project was not originally expected to be a migration; it was scoped and planned as an upgrade. The expectation of an upgrade was well-founded given the high-level scope of moving from one version to the next. Those involved with WebLogic Portal at the time know the move from 7.x to 8.x was in fact a migration rather than an upgrade. While there were some bridge APIs to allow the use of old code it was poorly suited to anything that was even slightly customized, which is to say every implementation in production. The project had been expected to take 4 – 6 weeks with one developer and actually took 10 weeks and 2 developers. It was the first of two migration/upgrades for the same customer and the lessons learned from the first move allowed the second move to be completed in 3 weeks with a single developer.

Fast-forward a decade and enterprises with WebLogic Portal are once again faced with a migration. This time we know up front that it will be a migration and IT managers along with their business customers are hesitant to move forward without a clear path to follow. While the last ten years have seen all J2EE-based portal products move to standard APIs for their foundation, they still have unique frameworks that serve as (from the vendors point-of-view) market differentiator and (from the customers perspective) a new form of vendor lock-in. In the case of WebLogic Portal, the vendor remains the same (albeit through acquisition) yet there is still no easy way to switch to the newer version, and a risk to staying with the old as it has been feature-frozen since 2010 and is slated for “sustaining-only support”.

The migration path from WebLogic Portal (WLP) to WebCenter Portal (WCP) is unclear for many reasons. Perhaps the most common and least-realized barrier to an “automated” migration is that WLP in his current form has 10 years of layered patches and deprecated-yet-still-in-production APIs supporting features that are a broad amalgam of proprietary solutions and customized integrations with standard APIs fueled by a demanding customer base for a (relatively) small vendor where WCP’s current form is currently a little over 3 years old and managed by a company that believes in setting the standards and letting the market follow.

Another source of great confusion is the mixed messages over time and between messengers as to whether a staged migration is practical or if it must be done in either a parallel phase out or big bang approach. To make that even more confusing, all of those options are equally the “best” approach, though the true determination of the correct approach is specific to a combination of the enterprise time-to-market needs, development skill sets, ability to maintain multiple environments and maturity of the enterprise architecture.

Given all these contributors to the fear, uncertainty and doubt surrounding a move off of a long-lived portal platform to a new, unfamiliar technology landscape I am currently in the process of acting as guide down this winding path for a company where all the various factors pointed mostly in the direction of a staged migration.

Like that first move to WLP 8.x, the approach from the 20,000 foot elevation looked very simple and straight-forward. Build the header, footer and navigation components in WebCenter and consume all of the legacy WebLogic Portal-produced portlets over WSRP. Where the WLP application had a backing file at the desktop-level that assembled user and account information at log-in, the backing file would be modified for use at the portlet level and the rest would be easy-peasy. This original understanding was entirely correct except the last phrase, i.e., no easy-peasy.

To be continued…

References for Historical Release Dates

http://en.wikipedia.org/wiki/Oracle_WebLogic_Server

http://en.wikipedia.org/wiki/Oracle_WebCenter

If you found this interesting, please share.

© Scott S. Nelson

It’s the Little Tags that Count

Scott S NelsonLeave a comment

In my on-going (and infrequent) effort to post tidbits about migrating from WebLogic Potal to WebCenter Portal I ran across this little reminder today:

WSRP does not support redirects. I’m not sure if that is per the WSRP 2.0 Specification or just the way Oracle goes about it, but for those of us working with WebCenter it doesn’t matter.

So, when doing a staged migration from WebLogic Portal to WebCenter where you have JSF portlets in WLP, in addition to making sure you update your pages to use UTF-8, check your faces-config.xml and look for navigation cases like this:

<navigation-case>
	<from-outcome>goBack</from-outcome>
	<to-view-id>/pages/SOLandingPage.jsp</to-view-id>
	<redirect/>
</navigation-case>

And remove the

<redirect/>

Failure to do so will cause all of your JSF WSRP page transitions to blow up in annoying ways.

Note that this discovery was by a team member who then passed it on to me.

If you found this interesting, please share.

© Scott S. Nelson