WebSphere brand IBM WebSphere Sensor Events, Version 6.2

General troubleshooting tips

This topic describes problems that might occur and provides possible solutions.

Something is wrong with Location Awareness Services for WebSphere Sensor Events and I do not understand the problem

Verify that all of the path settings in the System Properties portlet are correct.

Exceptions in the WAS_PROFILE_HOME\logs directory

Multiple log4j-1.2.13.jar files

If you see an exception in the WAS_PROFILE_HOME\logs file that looks similar to this example, then a possible cause for this exception is that there is more than one copy of the log4j-1.2.13.jar file:

[31.10.06 16:43:25:246 CET] 0000000a SystemErr     
     R log4j:WARN custom level class [com.ibm.atlas.logging.AtlasLevel] 
     does not have a constructor which takes one string parameter
[31.10.06 16:43:25:246 CET] 0000000a SystemErr     
     R java.lang.NoSuchMethodException: com.ibm.atlas.logging.AtlasLevel.toLevel
     (java.lang.String, org.apache.log4j.Level)
	at java.lang.Class.getMethod(Class.java:1078)
	at org.apache.log4j.helpers.OptionConverter.toLevel(OptionConverter.java:209)
	at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:588)
	at org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers
     (PropertyConfigurator.java:524)
	at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:408)
	at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:432)
	at org.apache.log4j.helpers.OptionConverter.selectAndConfigure
     (OptionConverter.java:460)
	at org.apache.log4j.LogManager.<clinit>(LogManager.java:113)
	at org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:543)
	at com.screamingmedia.openportlet.common.log.Log4jSvr.init(Log4jSvr.java:52)
	at javax.servlet.GenericServlet.init(GenericServlet.java:256)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:275)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1400)
	at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(
     WebExtensionProcessor.java:86)
	at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:793)
	at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:520)
	at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:409)
	at com.ibm.ws.webcontainer.webapp.WebGroup.addWebApplication(WebGroup.java:115)
	at com.ibm.ws.webcontainer.VirtualHost.addWebApplication(VirtualHost.java:128)
	at com.ibm.ws.webcontainer.WebContainer.addWebApp(WebContainer.java:939)
	at com.ibm.ws.webcontainer.WebContainer.addWebApplication(WebContainer.java:892)
	at com.ibm.ws.runtime.component.WebContainerImpl.install(WebContainerImpl.java:167)
	at com.ibm.ws.runtime.component.WebContainerImpl.start(WebContainerImpl.java:391)
	at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1228)
	at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart
     (DeployedApplicationImpl.java:1067)

My system did not automatically reconnect after a network failure and I did not receive a fatal error telling me to restart my browser

It is possible that the network retry values are set for an excessively long period of time. In theory, there are no maximum values for networkRetryInterval, maxNetworkRetries, or maxNoResponseDisplayManager; however, if you set the at numbers that are too high, the recovery system tries for a long time. The values are used in two formulae:
  • networkRetryInterval x maxNetworkRetries = The time spent trying to reconnect to the network before giving up.
  • maxNoResponseDisplayManager = The number of times the software attempts to read tag data from the server before giving up and sending a fatal error.

    This value should be no greater than 60,000 ms (the number of seconds to wait).

Open the IHS_HOME\htdocs\en_us\Tracking GUI\xml\prefsV3.xml file with a text editor and reduce the values for the following parameters:

The browser window hangs up and then the browser crashes

Location Awareness Services for WebSphere® Sensor Events may have crashed. Restart the browser.

I had a browser error, but refreshing the page did not correct the problem

The application attempts to perform error recovery but it is not always possible to recover from an error. Restart the browser.

I had a browser error message, and I selected the attempt to recover option. But it did not correct the problem, and I got the error message again.

The application attempts to perform error recovery but it is not always possible to recover from an error. Restart the browser.

I cannot stop server1 using the GUI menu

Try using the command line interface:

  1. Navigate to the WAS_PROFILE_HOME\bin directory.
  2. From a command prompt, issue the following command to stop WebSphere Application Server:
    Note: Keep in mind that the user IDs and passwords could be different on your system. You do not have to specify user and password, if WebSphere Application Server security is not enabled.
    stopServer server1 -username wpsbind -password wpsbind 

Tag processing does not seem to stop

If you stopped tag processing on the Control Processing portlet in the WebSphere Application Server administrative console and the tags are still moving on the Spatial Management Client or you can see that Location Awareness Services for WebSphere Sensor Events is still retrieving events from the dispatcher, do the following:

  1. Stop the dispatcher, if you are using it.
  2. Stop tag processing again.
  3. To restart tag processing with the dispatcher, start the dispatcher before starting tag processing.

If necessary, repeat the steps.

Chinese characters are not displayed properly on English Windows® 2003 Server operating system

Chinese characters (or any other non-standard ASCII characters) can be displayed after installing the corresponding languages.

Event information might contain inconsistent times in event date and message

If the location event information contains inconsistent times in the event date and message, the problem might occur because the DB2® server time and the WebSphere Application Server time are not synchronized. In order to solve this problem, prior to running your configuration, it is recommended that you synchronize these server times because location events use the DB2 server time for event creation, but CEI (Common Event Infrastructure) events use the WebSphere Application Server time for event creation.

The following is an example of event information that contains inconsistent times in the event date and message:
Event Date
Fri Feb 22 14:12:41 CET 2008 

Event Type
LasZoneEntry 

Event Message
Tag [00000007] with label [] entered zone 
[abc1234567d] at [Fri Feb 22 11:12:41 CET 2008] 
inadmittedly. Details: Classes: [New Class?], Groups: 
[Printer?] 

Rule violation detected with some delay

If Duration of Stay in Zone or Visitor Escorting rule violations are detected with some delay, check whether their respective Maximum duration of stay or Maximum tolerated rule violation time values are less than 30 seconds. If either of these timeout values are less than 30 seconds, change the settings of the scheduler for the Business Rules engine. To change the settings of the scheduler for the Business Rules engine:
  1. From the WebSphere Application Server administrative console, navigate to Resources > Schedulers > AMITSCHEDULER.
  2. Set the Poll interval parameter to the minimum value for the Maximum duration of stay and the Maximum tolerated rule violation time parameters in your rule instances.

Exception in the SystemOut.log file but no obvious failure

After you start tag processing and successfully access and use the Spatial Management Client, you could see an exception similar to the following example:

[8/13/08 10:30:22:421 EDT] 00000037 SRTServletReq E   
SRVE0133E: An error occurred while parsing parameters. java.io.IOException: 
Async IO operation failed, reason: RC: 55  The specified network resource or 
device is no longer available.

at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:671)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)

This is a known limitation in WebSphere Application Server, and requires no action at this time. See the APAR description for this issue at: http://www.ibm.com/support/docview.wss?uid=swg1PK72336.

Not all socket hub connections can start

If many of your event providers are defined in Location Awareness Services for WebSphere Sensor Events with socket hub connections, but you can only connect to a few of them, check the work manager settings for the JNDI name, wm/IBMAtlas. Modify the Maximum number of threads value to the number of event providers you have multiplied by three.

SQL error message in LOG_ATLASDB_CreateStProc.txt file after installing Location Awareness Services for WebSphere Sensor Events

If you are installing Location Awareness Services for WebSphere Sensor Events 6.1.0.2 without a previous version of the component installed, you could see an error in the LAS_HOME\logs\LOG_ATLASDB_CreateStProc.txt file that is similar to the following:

DROP PROCEDURE IBMATLAS.SEARCHDATA (INTEGER, TIMESTAMP)
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0458N  In a reference to routine "IBMATLAS.SEARCHDATA" by signature, a 
matching routine could not be found.  SQLSTATE=42883

DROP PROCEDURE IBMATLAS.HEADCOUNTBYZONE (TIMESTAMP, CHAR(1))
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0458N  In a reference to routine "IBMATLAS.HEADCOUNTBYZONE" by signature, a matching routine 
could not be found.  SQLSTATE=42883

DROP PROCEDURE IBMATLAS.BATLIFEREPORT ()
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0458N  In a reference to routine "IBMATLAS.BATLIFEREPORT" by signature, a 
matching routine could not be found.  SQLSTATE=42883

DROP PROCEDURE IBMATLAS.LASTSEENREPORT (TIMESTAMP, CHAR(1), VARCHAR(256), VARCHAR(256), 
VARCHAR(32))
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0458N  In a reference to routine "IBMATLAS.LASTSEENREPORT" by signature, a matching routine 
could not be found.  SQLSTATE=42883

You can safely ignore this error.

General exception when working with the Control Processing portlet

If you have Location Awareness Services for WebSphere Sensor Events security enabled and you are working with the Control Processing portlet, you could see a general exception. As long as the status of the event providers are changing as expected, then you can safely ignore the exception.


Library | Support | Terms of use

(c) Copyright IBM Corporation 2004, 2009. All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.