Showing posts with label websphere. Show all posts
Showing posts with label websphere. Show all posts

14 September 2015

Application on a separate custom port - Webspher Application Server 8.5

I've just spotted a question on developerworks forum whether it's possible to run one of the applications on Websphere Application Server on a separate, custom port. There's a way to achieve this and in this post I'm going to show how to do it.

1. First, we need to define a new port for our server. Go to Application servers -> your server -> Ports, anc click New....


Type in non-standard value (eg. 9081) and a custom name (WC_customPort)
Click OK and save the changes, and you will see your newly added port on the list:
But there's a small culprit now - we got the port, but "No associated transport" means that nothing really listens on the requests on this port. That's why we need to define a new transport chain for our port.

2. The new transport chain will essentially be identical to existing default transport chain. To create it we need to  go to Application servers -> Web container -> Web container transport chains:

Click New... and create on from webContainer template:


Click Next, and pick the existing port created in step 1. (as you can see, WAS could have made this for us in this place)

Confirm the data on the last screen and click Finish, save changes and you should have your new transport chain on the list:


We're almost ready: we've got the port and transport associated with it, but we still have no way to map our application to a different port, because we only have one default virtual host defined for standard 9080 port:


3. Let's create a new virtual host then:




Now, go again into custom_host, and go to Mime Aliases screen and define it to be 'any' (*) host, port 9081:


Click OK, save changes. The only thing remaining now is to map the application you want to use on custom port to this new virtual host. Go to Enterprise Applications > Your application > Virtual hosts and map it to custom_host:



All necessary changes have been made, so be sure you save them to server's config and restart the server. And there we go, after server reboot, we have two different applications on two different ports:



In this post I showed how to make J2EE application running on Websphere Application Server 8.5 use custom, non standard port along with other applications running on default web container port. I hope this helps you and if you have any questions, feel free to post it in comments.

Good day, and good luck to you!

21 January 2014

DSRA0302E: XAException. Error code: XAER_RMERR (-3). Exception:

It's been published in several places, I guess but for the sake of simplicity:

Websphere 8.5, Oracle 11.2, datasource and transactions. You start your WAS server and see this in the logs:

[20.01.14 13:36:43:670 CET] 0000004f WSRdbXaResour E   DSRA0304E:  Wystapil wyjatek XAException. Tresc i szczególy wyjatku XAException: The cause is               : null.
[20.01.14 13:36:43:671 CET] 0000004f WSRdbXaResour E   DSRA0302E:  Wystapil wyjatek XAException.  Kod bledu: XAER_RMERR (-3).  Wyjatek: <null>
[20.01.14 13:36:43:671 CET] 0000004f XARminst      E   WTRN0037W: Usluga transakcji napotkala blad w operacji xa_recover. Zasób: com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl@c6a9f4fb. Kod bledu: XAER_RMERR. Dane sledzenia stosu wyjatku: javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:709)
at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.recover(WSRdbXaResourceImpl.java:1116)
at com.ibm.ws.Transaction.JTA.XARminst.recover(XARminst.java:141)
at com.ibm.ws.Transaction.JTA.XARecoveryData.recover(XARecoveryData.java:716)
at com.ibm.tx.jta.impl.PartnerLogTable.recover(PartnerLogTable.java:431)
at com.ibm.tx.jta.impl.RecoveryManager.resync(RecoveryManager.java:1534)
at com.ibm.tx.jta.impl.RecoveryManager.performResync(RecoveryManager.java:2267)
at com.ibm.ws.tx.jta.RecoveryManager.performResync(RecoveryManager.java:117)
at com.ibm.tx.jta.impl.RecoveryManager.run(RecoveryManager.java:2220)
at java.lang.Thread.run(Thread.java:772)

the key is:

javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:709)

as there are some pending, unrecoverable transaction in the transaction log. there are two ways to deal with it:
- start your server, nevermind your business applications not working, go to console, Application servers > server1 > Transaction service, then to Runtime tab and there you can see some options to manually manage pending troublesome transactions:


- or alternate: stop server, go to <profileroot>/tranlog/(respective path)/tranlog & partnerlog, delete tranlog and partnerlog files. start server.

Now, the way no. 2 is advisable for development systems, where any data loss is irrelevant. For production, proceed with care and try way no.1 first. Should it fail, go hardcore and delete tranlog.
Good luck.

02 October 2013

WAS 8.5 Trace missing - SLF4J: Class path contains multiple SLF4J bindings

It's been quite long since I posted here. Yet I have one new tip for you today:

The problem was that WebSphere 8.5 server did not recognize components to trace after application deployment, and after finally appearing in the traceable components tree did not log all expected output to trace log. As a result we wasn't able to troubleshoot the installation, not to mention that some of the log output was required by defined use cases of the designed solution.


After some search, asking here and there, a colleague of mine (thanks, Agnieszka!) noticed the following entries in the SystemOut.log file of the server when the troublesome application was deployed:


10/2/13 13:42:10:331 CEST] 00000042 SystemErr     R   SLF4J: Class path contains multiple SLF4J bindings.
[10/2/13 13:42:10:331 CEST] 00000042 SystemErr     R   SLF4J: Found binding in [bundleresource://243.fwk-1319487885:1/org/slf4j/impl/StaticLoggerBinder.class]
[10/2/13 13:42:10:331 CEST] 00000042 SystemErr     R   SLF4J: Found binding in [wsjar:file:/opt/ibm/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/xxxxx/lib/slf4j-jdk14-1.6.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
[10/2/13 13:42:10:332 CEST] 00000042 SystemErr     R   SLF4J: Found binding in [wsjar:file:/opt/ibm/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/xxxxx/lib/slf4j-log4j12-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
[10/2/13 13:42:10:332 CEST] 00000042 SystemErr     R   SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
[10/2/13 13:42:10:357 CEST] 00000042 SystemErr     R   SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]

and apparently this was causing the server to make wrong class pickup the logging (and hence missing output as that class missed appropriate configuration).

I came up with the idea of removing one of the conflicting classes from ear with console option "Remove file" and selecting whole jar (lib/slf4j-log4j12-1.7.2.jar). After application restart logging started to work as expected!


Good luck!


Env: WebSphere 8.5.0.2 ND, Linux rhel 6 64bit, application build with Maven (some predefined class includes defined).

20 September 2012

commonDBUtility.ant Source file does not exist! during WebSphere ESB DMgr creation

When creating ESB DMgr profile you may encounter the following error in the log:


<date>Sep 20, 2012 10:47:53 AM</date>
    <millis>1348130873432</millis>
    <sequence>10111</sequence>
    <logger>com.ibm.ws.install.configmanager.actionengine.ant.utils.ANTLogToCmtLogAdapter</logger>
    <level>WARNING</level>
    <class>com.ibm.ws.install.configmanager.logging.LogUtils</class>
    <method>logException</method>
    <thread>0</thread>
    <message>/opt/websph/ESB/util/dbUtils/profileHelpers/commonDBUtility.ant:985: Source file does not exist!
at org.apache.tools.ant.taskdefs.SQLExec.execute(SQLExec.java:324)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)

(...)

and resulting:


<record>
    <date>Sep 20, 2012 10:47:53 AM</date>
    <millis>1348130873556</millis>
    <sequence>10164</sequence>
    <logger>com.ibm.wsspi.profile.WSProfileCLI</logger>
    <level>INFO</level>
    <class>com.ibm.wsspi.profile.WSProfileCLI</class>
    <method>invokeWSProfile</method>
    <thread>0</thread>
    <message>Returning with return code: INSTCONFFAILED</message>
</record>
</log>

This happened to my colleague, who was configuring ESB DMgr against Derby network server. We spent a while figuring out what's wrong. Closer look into logs couple of lines before first error showed

<message>Target stopped for: init.db - SUCCESS</message>

so the Derby DB was initialized fine. Right afterwards we found:

 <message>Execute SQL script with parameters: JDBCDriver='org.apache.derby.jdbc.ClientDriver' DB_URL='jdbc:derby://localhost:1527//opt/websph/ESB/profiles/Dmgr2/databases/WPRCSDB4' dbUserId='admin' sqlScriptPath='/opt/websph/ESB/profiles/Dmgr2/dbscripts/CommonDB/Derby/WPRCSDB4/createTable_CommonDB.sql' JDBC_DRIVER_FILE_STATIC='/opt/websph/ESB/derby/lib/derbyclient.jar'</message>

following this trail I asked my buddy to check dbScriptOutputDir content. Bingo! it contained the following structure:

/opt/websph/ESB/profiles/Dmgr2/dbscripts/CommonDB/Derby/WPRCSDB4/CommonDB/Derby/WPRCSDB4/pliki.sql

with clearly abundant subtree portion. The reason for this was that in the manageprofiles dbScriptOutputDir  parameter contained unnecessary tail that is created automatically. Hence, ant script failed not finding sql files where expected. Changing

./manageprofiles.sh -create  (...) -dbOutputScriptDir '/opt/websph/ESB/profiles/Dmgr2/dbscripts/CommonDB/Derby/WPRCSDB2'

to 

./manageprofiles.sh -create (...) -dbOutputScriptDir '/opt/websph/ESB/profiles/Dmgr2/dbscripts'

did the trick. Please note that InfoCenter says you need to do it wrongly! Look here (Table 2, -dbOutputScriptDir description. Thank you Rafał!)

Good luck!

30 July 2012

HPDAZ0602E Corrupted file: Insufficient information to contact a Policy Server (SECJ0391E)

Now, a few words about possible problems when configuring external JACC authorization provider for WebSphere App Server, namely - Tivoli Access Manager. The key issue here always lies in obtaining Policy Server's certificate for JRE to authenticate later on. This can be done in various ways (sslsrvcfg, pdconfig etc.) and obviously, the results may vary depending on the way used - at least it seems so.
Anyway, recently I was asked what may be the reason for the following error appearing in the logs:

[7/25/12 10:07:44:950 CEST] 00000013 AMWASConfigMe I   com.tivoli.pd.as.jacc.cfg.TAMConfigController execute() AWXJC0048E   An error occurred during the configuration. The details are: com.tivoli.pd.as.jacc.cfg.ConfigActionFailedException:
[java.lang.IllegalStateException: HPDAZ0602E   Corrupted file: Insufficient information to contact a Policy Server.
]

Wrappered Exception:
java.lang.IllegalStateException: HPDAZ0602E   Corrupted file: Insufficient information to contact a Policy Server..


This one happened during JACC configuration attempt from the WAS admin console, when console reported that action cannot be successfully completed. "Insufficient information" could only mean that JRE is trying to register with Policy Server, but fails to trust/present valid certificate. Unfortunately, we were stubborn, and hoped that action will complete during server restart. But after saving configuration and restarting server, it fails to start! In the logs we could see:

[7/25/12 10:19:49:404 CEST] 00000000 distSecurityC E   SECJ0391E: Error when setting the Policy object to the provider's policy implementation com.tivoli.pd.as.jacc.TAMPolicy. The exception is com.tivoli.pd.as.jacc.util.JACCException: AWXJR0006E   The file, /opt/ibm/WebSphere/AppServer/profiles/PSS1UPRB01DMgr/etc/tam/amwas.PSS1UPRB01DMgr_dmgr.amjacc.properties, was not found.
    at com.tivoli.pd.as.jacc.TAMPolicy.init(TAMPolicy.java:680)
    at com.tivoli.pd.as.jacc.TAMPolicy.<init>(TAMPolicy.java:97)
    at java.lang.J9VMInternals.newInstanceImpl(Native Method)
    at java.lang.Class.newInstance(Class.java:1345)


which meant that WAS has got JACC enabled, but in fact had failed to provide proper configuration file for amwas/jacc. We gave it some thinking and first, we had to recover from this fatal condition: by editing security.xml we disabled security and disabled using JACC in section:

<security:Security xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:orb.securityprotocol="http://www.ibm.com/websphere/appserver/schemas/5.0/orb.securityprotocol.xmi" xmlns:security="http://www.ibm.com/websphere/appserver/schemas/5.0/security.xmi" xmi:id="Security_1" useLocalSecurityServer="true" useDomainQualifiedUserNames="false" enabled="true" cacheTimeout="600" issuePermissionWarning="false" activeProtocol="BOTH" enforceJava2Security="false" enforceFineGrainedJCASecurity="false" appEnabled="true" dynamicallyUpdateSSLConfig="true" allowBasicAuth="true" activeAuthMechanism="LTPA_1" activeUserRegistry="WIMUserRegistry_1" defaultSSLSettings="SSLConfig_1"> <--- change bold to FALSE


<authConfig xmi:id="AuthorizationConfig_1" useJACCProvider="true">  <-- change bold to FALSE   


After that server went up again and we gave a bit thinking to the problem. It turned out to be awfully simple and...well, strange ? We had to add hostname of the WAS machine to policy server's /etc/hosts. Possibly this can be also solved by adding WAS hostname to DNS, anyway, pdmgrd must be able to resolve WAS's IP based on presented hostname. Then, we were able to complete JACC configuration successfully, turn security back on for the whole cell, save and restart and all worked like a wonder!

Why do I say it was strange? Because my suspicion is that different PD.jar packages (or more precisely: pd.* classes) responsible for connecting to Policy Server do this in a different way. I'm too weak a programmer to dig this up and resolve it 100%, but I just know that you may get different results when a) configuring JRE from pdconfig b) using sslsrvcfg and c) configuring JACC from WAS (WebSphere's embedded TAM) - eventually, you just need to see what works best for you.

Good luck, leave a comment if it helped!



07 March 2012

javax.management.JMRuntimeException: ADMN0022E


If you stumble upon the following error:

See nested exception; nested exception is: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the getChain operation on TransportChannelService MBean because of insufficient or empty credentials.

that means you need to revise your application permissions settings. That is, your application most probably has a RunAs role defined, which determines identity that is being mapped to each appliacation call - WebSphere then "thinks" that each call to this EJB is being made by some specified user (RunAs).
To check this, go to:

Applications > Enterprise Applications > application_name 

and find  Map RunAs roles to users under Additional Properties section. There you will find RunAs roles defined for this particular EJB. What you need to do is to type in valid username and password (having necessary permission level if you are using any authorization system - either role-based or external, like calling PDContext for TAM authorization), tick roles you want to assign them to and use Aplly, then save, synchronize and restart server.

Detailed information can be found on IBM InfoCenter.

Good luck, leave a comment or vote in the poll, please :) 

27 February 2012

IBM HTTP Server not starting - http_plugin.log excess size

I just happened to come across the following error:
I'm using IBM HTTP Server 7 with WAS Plugin configured. the following behavior was observed - after attempting to start IHS with 

<IHS_INSTALL_ROOT>/bin/apachectl start

control returns to shell, as it should. But when I checked if IHS is up and running with

nestat -an | grep <portnumber>

it didn't show desired port listening, however when looking for httpd processes with:

ps -ef | grep httpd

showed all necessary httpd jobs (namely, 4 of them). That is a problem symptom.

This was the second time I came across that, so I knew what to do. The clue is http_plugin.log file size: when it grows over 2147483647 bytes (on Linux), OS is no longer able to write to it, and despite seemingly successful startup of the server. So, you just need to remove (or move to other place if you need it) this file, and try to start IHS again, it will recreate it and work fine. The log file is located in <PLUGIN_ROOT>/logs/<Servername>/http_plugin.log

If you happen to see this malfunction, review your WAS plugin LogLevel settings. Remeber that on Trace or Detail level it generates fairly lot of entries and log grows very quickly. If your system is working fine and you don't have any sophisticated file log monitoring implemented, just change it to Info or Warn - it will be sufficient and your log file won't clog up.

Good luck,  thanks for comments and feedback!

07 February 2012

SECJ0053E and AWXJR0044E: PolicyConfiguration exists = false

If you are working on WAS with JACC configured against Tivoli Access Manager (or other external authorization provider, but I assume TAM is the most popular) in your application development cycle you may stumble upon the following error sequence:
[2/7/12 11:24:45:304 CET] 000000c8 SecurityColla A   SECJ0053E: Authorization failed for defaultRealm/username while invoking (Bean)XyEAR-2.2#XyzBean.jar#soapAction:5 JACC Authorization failed for bean: xyzvBean
[2/7/12 11:24:45:660 CET] 0000003d AMWASJACCMess I   com.tivoli.pd.as.jacc.TAMPolicy implies(ProtectionDomain, Permission): permission = perm.toString()
0x864297004
AWXJR0044E   The access decision for Permission, (javax.security.jacc.EJBMethodPermission xyz), was denied because either the PolicyConfiguration or RoleConfiguration objects did not get created successfully at application installation time.  RoleConfiguration exists = true, PolicyConfiguration exists = false.

It is more probable to occur right after application update (new version deployed, for instance).

Here are the things you may do to steer out of this trouble:

 


  1. Ensure all necessary protected object exist in TAM policy database (use pdadmin or WPM - TAM console deployed on WAS)
  2. Update role definition in your authorization provider with:

    Global security > External authorization providers

    choosing "Update with application names listed" and typing in your application name (as appears in Enterprise Applications tab), then Apply

  3. If point 2. fails, follow this sequence: stop application, remove application from server, stop application server, clean temp directories for this server, start server and redeploy application. It should bind with TAM properly this time. After that, restart the server again.
 Good luck.

25 January 2012

Java exception: org.omg.CORBA.BAD_INV_ORDER

It may happen that all of a sudden you will see the following exception in your SystemOut.log of your managed server (that is the one managed from deployment manager console via nodeagent process). That may occur during either server run or (more often) during server startup attempted from shell level.

[1/25/12 11:25:36:870 CET] 0000002c WSSecurityCon A   Error creating client_auth_token in initSecContext, reason: Major Code[15] Minor Code[0] Message[ create_gss_initial_context_token: Java exception: org.omg.CORBA.BAD_INV_ORDER: ORB has been shut down  vmcid: OMG  minor code: 4  completed: No]
[1/25/12 11:25:36:884 CET] 0000002c IPCConnectorC E   ADMC0076E: Failed to get security token due to Major Code[15] Minor Code[0] Message[ create_gss_initial_context_token: Java exception: org.omg.CORBA.BAD_INV_ORDER: ORB has been shut down  vmcid: OMG  minor code: 4  completed: No]
        at com.ibm.ISecurityUtilityImpl.CSIUtil.create_gss_initial_context_token(CSIUtil.java:979)
        at com.ibm.ISecurityLocalObjectTokenBaseImpl.WSSecurityContextLTPAImpl.initSecContext(WSSecurityContextLTPAImpl.java:179)
        at com.ibm.ISecurityLocalObjectTokenBaseImpl.WSSecurityContextLTPAImpl.initSecContext(WSSecurityContextLTPAImpl.java:133)
        at com.ibm.ws.management.connector.ipc.IPCConnectorClient.fillInCredential(IPCConnectorClient.java:307)
        at com.ibm.ws.management.connector.ipc.IPCConnectorClient.queryNames(IPCConnectorClient.java:792)
        at com.ibm.ws.management.AdminClientImpl.queryNames(AdminClientImpl.java:108)
        at com.ibm.ws.management.discovery.transport.MBeanDiscoveryHelper.discovery(MBeanDiscoveryHelper.java:507)
        at com.ibm.ws.management.discovery.transport.MulticastServer.rediscover(MulticastServer.java:406)
        at com.ibm.ws.management.discovery.transport.MulticastServer.run(MulticastServer.java:279)
        at java.lang.Thread.run(Thread.java:736)


It usually means that your server has lost communication with it's nodeagent, and the reasons for that may be numerous, but the most common are:
  • nodeagent process crashed or was killed any other way - that is the easiest: just bring up back the nodeagent
  • something went wrong with network interfaces (that's more applicable to startup problem) - in that case you need to try to bring up/down lo interface (read here) or check if in the meantime your hostname or ip address hadn't been changed (little chance, but you never know)
  • if above fail, check if nodeagent NDS (node discovery service) port, among with other ports (soap etc.) are locally available with telnet. if not, you need to diagnose further system's ip sockets setup.
Good luck!

19 January 2012

WebSphere JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security.

If you see the following exception while or after starting your server (nodeagent or app server): 

JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. 


then big chance is that there's something wrong with internal certificates between WAS instances, either:
1. Hostname has been changed and hostname verification is turned on in SSL setup. you may check this here:
http://www.ibm.com/developerworks/websphere/techjournal/0612_birk/0612_birk.html
in paragraph:

The default trust manager, IbmX509, performs fundamental certificate validation, including the certificate signature validation (ensuring it has not been modified) and certificate expiration validation (ensuring it has not expired). This trust manager does not perform hostname verification by default, although you can set the com.ibm.ssl.performURLHostNameVerification=true property in the security custom properties to enable this function for URL connections only. If this is done, the trust manager will ensure that for URL connections, the hostname specified on the connection matches the SubjectDN in the certificate returned by the server (just as Web browsers do).
(recommend reading the whole article btw.)

2. Something went horribly wrong in terms of cell synchronization, so I'd suggest stopping servers and nodeagent on remote machine and running ./syncNode.sh from profile's bin directory. not sure it will work as probably wsadmin script client won't be able to connect to SOAP port due to root cause. hence, we're back at point 1. and I guess only manual copying of trust/keystores from dmgr machine to remote machine might help.


hope this helps, or at least points to the right direction.

16 January 2012

WebSphere SOAP message trace (XML, JAX-WS)

Okay, there are numerous articles on how to trace XML SOAP messages sent to websphere server, but it seems all of them address some different scenario I am in. Eg. they involve custom development or code-changing in order to add handlers and so on.
What I needed was to simply dump content of SOAP messages incoming to my http inbound channel. However, anything less than wssecurity.*=all given no SOAP content, so I started to drill down to the very one I needed. Finally I found some least fraction of WAS framework to check if you want to get incoming XML content, out of WSSecurityHandler class. As XML parsing involves security processing, you simply need to use the following trace:

com.ibm.ws.wssecurity.handler.*=finest 

in addition to the one you already have set.

Good Luck, I wish you happy tracing!

13 January 2012

WebSphere: disable SSL between IHS and WAS (IHS SSL offload)

Ever wondered how to disable SSL between IHS and WebSphere App Server? In some environments, your IHS and WAS remain in secure zone, and you don't want to spend any CPU time for doing SSL between web server and backend server.
In case of IBM HTTP Server + WAS combination there's a simple way to do it:

  • assuming you have Plugin already configured for IHS, you need to edit it's config (plugin-cfg.xml) with some editor eg. vi
  • find section for your backend server cluster you want to SSL off-load:
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="clustername" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">
      <Server ConnectTimeout="5" ExtendedHandshake="false" MaxConnections="-1" Name="PTS2CSIP01Node_STS2CSIP01S01" ServerIOTimeout="60" WaitForContinue="false">
         <Transport Hostname="backend_hostname" Port="4300" Protocol="http"/>
         <Transport Hostname="backend_hostname" Port="4343" Protocol="https">
            <Property Name="keyring" Value="/opt/ibm/HTTPServer/Plugins/config/plgcfgname/plugin-key.kdb"/>
            <Property Name="stashfile" Value="/opt/ibm/HTTPServer/Plugins/config/
plgcfgname/plugin-key.sth"/>
         </Transport>
      </Server>
   </ServerCluster>


 and comment out second Transport definition to:

      <!--Transport Hostname="backend_hostname" Port="4343" Protocol="https">
            <Property Name="keyring" Value="/opt/ibm/HTTPServer/Plugins/config/
plgcfgname/plugin-key.kdb"/>
            <Property Name="stashfile" Value="/opt/ibm/HTTPServer/Plugins/config/
plgcfgname/plugin-key.sth"/>
      </Transport-->
 

  • restart your IHS server and check in error_log if plugin has been loaded properly 
To check, you may turn on plugin tracing:

<Log LogLevel="Trace" Name="/opt/ibm/HTTPServer/Plugins/logs/plgcfgname/http_plugin.log"/>

Restart IHS once again and tail  http_plugin.log while sending request to your https port of IHS. You shall get trace like that:
TRACE: ws_common: websphereFindTransport: Finding the transport
DETAIL: ws_common: websphereFindTransport: Setting the transport(case 3): backend_hostname on port 4300 <--- PLEASE NOTE THIS IS HTTP PORT OF WAS!
TRACE: ws_common: websphereExecute: Executing the transaction with the app server reqInfo is OKuseExistingStream=0, client->stream=(nil)
DEBUG: ws_common: websphereGetStream: Getting the stream to the app server
TRACE: ws_transport: transportStreamDequeue: Checking for existing stream from the queue
TRACE: ws_common: websphereGetStream: Have a connect timeout of 5; Setting socket to not block for the connect
TRACE: ws_common: websphereGetStream: Reseting socket to block
TRACE: ws_common: websphereGetStream: Setting socket to non-block for ServerIOTimeout over HTTP
DEBUG: ws_common: websphereGetStream: socket 13 connected to
backend_hostname:4300
DEBUG: lib_stream: openStream: Opening the stream
DETAIL: ws_common: websphereGetStream: Created a new stream; queue was empty, socket = 13


Any questions? Good Luck!!! Feel free to comment&leave feedback.

    04 January 2012

    WebSphere WPS/ESB CWSIS1538I,CWSIS1545I,CWSIS1535E and CWSIS1546I

    When working with WebSphere Process Server (or Enterprise Service Bus, which is a limited set of WPS functionality) you may run into a problem with using database for messaging engines. That appears as a series of errors in SystemOut.log file during particular server startup, while the errors are: CWSIS1538I,CWSIS1545I,CWSIS1535E and CWSIS1546I. That usually means that you are trying to re-use SIB tables in the database, that were previously used by another WebSphere instance. Good example of this problem is given here in infoCenter but to say short that is what you need to do:
    • find database used by WPS/ESB
    • check if <YOURSCHEMA>.SIBOWNER table exists and what are it's contents (simply: SELECT * FROM <YOURSCHEMA>.SIBOWNER
    • you'll see that there's some ME UUID (messaging engine unique id) exists that is preventing WPS/ESB to start using this table exclusively (WPS needs to "know" that SIB tables are his and only his, so you need to ensure he can think so)
    • clear SIBOWNER table with DELETE * FROM <YOURSCHEMA>.SIBOWNER
    • restart the server and check if errors are gone
    My recommendation (as well as support's) is to clear all tables used by SIB engine (which ones? check out in DB generation ddls, produced by sibDDLGenerator.sh scripts) to ensure no further data conflict will occur in future.

    Good luck! Leave a comment!

    02 December 2011

    WebSphere console error SRVE0260E

    If when trying to log to a newly configured Deployment Manager in Websphere you see the following error with a stack dump:


    Error Page Exception
    SRVE0260E: The server cannot use the error page specified for your application to handle the Original Exception printed below.

    Original Exception:
    Error Message: java.lang.NullPointerException
    Error Code: 500
    Target Servlet:
    Error Stack:
    java.lang.NullPointerException
         at com.ibm.isclite.container.provider.PortletContainerContextProvider.addContainerService(PortletContainerContextProvider.java:101)



    then you need to raise your system limit for number of open files. on linux you do it with ulimit command:

    ulimit -f 8192

    where number depends on the DMgr console configuration - for standard WebSphere 1024 is sufficient, whereas with WebSphere Process Server 7 you need to raise it more, to, say, 8192.

    Using ulimit -f however sets ulimit for your shell session only, so next time when you restart dmgr in your shell you will hit the same problem again. You can either raise fopen parameter for your profile (in .profile) or for the whole system by inserting:

    #<domain>      <type>  <item>         <value>

    *               soft    nofile          8192


    to /etc/security/limits.conf. You must reboot your Linux in order for this change to take effect.

    But of course beware on the impact on your system and consider this change well.

    Good luck! Please leave a comment if my hint helped you and feel free to contact me on G+ !

    24 November 2011

    websphere addNode problem: ADMU0036E: The Deployment Manager cannot lookup by name host at address

    That's exactly what hit me: I was trying to federate node to deployment manager when I got this error:

    ADMU0036E: The Deployment Manager cannot lookup by name host .. at address 127.0.0.2

    I checked local config: no 127.0.0.2 address was there.
    I found this thread on developerWorks, and it helped me - I just needed to turn of loopback interface with:

    /etc/init.d/network stop lo

    After that addNode went smoothly.

    Software version: WAS 7.0.0.19, SLES 11.1