Remember: Examples are Just Examples

For example, the documentation at Using the WebLogic Server JMX Timer Service gives a very straight-forward and standards-compliant example of how to run a task at intervals.  I used this example almost in its entirety to create a module to poll a database for a specific change every 2o minutes. I then noticed that the timer would stop for no apparent reason at no obvious interval.

After many hours of digging through logs looking for some cause, I was ready to give in and post a plea for help on a mailing list. It just so happened used a text editor to grab the code to post, and noticed in the text editor that there was one place where unregister would be called on the bean: under contextDestroyed in the servlet to at registered the timer.  In the clarity of hind-sight I realized that the timer was stopping more often in environments that were accessed less often because the efficient WebLogic Server was garbage collecting the unused servlet handle, resulting in contextDestroyed being invoked, thus killing my timer. As it normally should, except in the case where the timer should continue running as long as the server was running.

Lesson learned: Think it all the way through between copy and paste.

For those who like links and confessions:  There is an example of using a timer in my JavaBoutique article that contains precisely the same flaw in logic.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Do Not Use Commas For Multi-Source JNDI

Here’s a bit of fun with WebLogic JDBC configurations.  I ran into this issue after reading that p13nDataSource and  cgDataSource-NonXA should not be configured as multi-source. There were  some issues changing them to use the basic JDBC connection string and  when rolling back to the bad configuration the server went “Boom”.  Since one purpose behind this blog is to share lessons learned, I just had to post this.

If you write your descriptors manually (as opposed to generating them using the WLS console) and put a comma-separated list of JNDI addresses like this:

<jdbc-data-source-params>
  <jndi-name>weblogic.jdbc.jts.commercePool,
	contentDataSource,
	contentVersioningDataSource,
	portalFrameworkPool</jndi-name>
  <algorithm-type>Load-Balancing</algorithm-type>
  <data-source-list>portalDataSource-rac0,
	portalDataSource-rac1</data-source-list>
  <failover-request-if-busy>false</failover-request-if-busy>
</jdbc-data-source-params>

so long as the first address resolves, it will still work. Sort of.  If you call this connection to do an update, only one node of the RAC instance is updated. Other wonderful side-effects include the server refusing to start sometimes.

The proper way to list the JNDI sources is one per node, like this:

<jdbc-data-source-params>
	<jndi-name>weblogic.jdbc.jts.commercePool</jndi-name>
	<jndi-name>contentDataSource</jndi-name>
	<jndi-name>contentVersioningDataSource</jndi-name>
	<jndi-name>portalFrameworkPool</jndi-name>
	<algorithm-type>Load-Balancing</algorithm-type>
	<data-source-list>portalDataSource-rac0,
			portalDataSource-rac1,
			portalDataSource-rac2
	</data-source-list>
	<failover-request-if-busy>false</failover-request-if-busy>
</jdbc-data-source-params>

 

(Props to Sandeep Seshan for locating the root cause)

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

com/compoze/collab/log/LogEntryPrototype Error

While attempting to deploy an application built by someone new to WLP recently, I was getting a bit frustrated with a recurring error about “java.lang.NoClassDefFoundError: com/businessobjects/log/Logger” in the dev environment and deployment errors about com/compoze/collab/log/LogEntryPrototype in the integration environment.

Long story short (actually did it this time!), the issue was that the developer edited weblogic.xml by hand using an older WLP application as a guide and included the following:

wlp-collab-portlets-web-lib
10.3.2
10.3.2
false

Which is only available in a GroupWare-enabled environment. Once I removed that, everything was fine again.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

JDBC BEA-001129

If you don’t have a LinkedIn membership, this discussion should be enough reason to sign up (for the record, I did not provide the responses to this question):

Q:

I have a problem in production environment with WebLogic 9.2 mp3.We are using Multi datasource with Oracle 9i RAC two nodes. Database team have maintaince so they took out one node out of RAC. when one of the WebLogic instance associated with connection pool to that RAC node shown the following Warning message and could not start the instance.The multi datasource is configured with algorithm-type as “Load-Balancing”

<Jun 3, 2010 3:12:23 AM EDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING>
<Jun 3, 2010 3:14:10 AM EDT> <Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool “DS2”: Io exception: The Network Adapter could not establish the connection>

What are the recommandations to avoid this kind of problems when one of the RAC nodes down and the WebLogic server should have High Availability and scalable?

Any configuration parameters need to set for this??

A:

The way 9.2 mp3 works with RAC is that the multidatasource represents a pool of datasources so if one datasource is not available it will mark that down and use the other datasources configured in the multidatasource. WLS controls the failover, not RAC and this version does not use FAN or FCF.

I assume you have test on reserve set in the connection of all the data sources as that is required to use multdatasource. This parameter is at datasource->connection pool-> advanced

“could not start the instance” means that WLS did not come up??

If you are bringing up a WLS instance without the DB up you may want to set initial connections to 0

Facebooktwitterredditlinkedinmail
© Scott S. Nelson