PQ59624: HTTP SERVER PORT HARDCODED: SHOULD BE CONFIGURABLE. | |||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description The default PORT for a given WebSphere Application Server is hardcoded to 9080. For the creation of a new HTTP Transport; the last used port [ starting from 9080] will be incremented. . Customer installing multiple instances of WAS on 1 physical node per IBM Websphere' coexistance recommendation will have to manually configure and maintain a list of TCP/IP ports used by difference instances of WAS. . The current implementation assumes that only 1 instance of WAS will be on a physical machine therefore a hardcoded starting port for HTTP Transports is acceptable; However this does not allow for multiple instances to be maintained and increases the administration work for Websphere.Local fix Maintain a list of Websphere Instances along with all the TCP/IP ports used by that Instance and manually configure a different port for each AppServer created.Problem summary **************************************************************** * USERS AFFECTED: WebSphere Application Server user running * * WAS4.0.2 or later needing to configure HTTP * * server port. * **************************************************************** * PROBLEM DESCRIPTION: The default PORT for a given App * * Server is hardcoded to 9080. For the * * creation of a new HTTP Transport; the * * last used port starting from 9080 * * will be incremented. * **************************************************************** * RECOMMENDATION: * **************************************************************** When installing multiple instances of WAS on one physical node per the IBM WebSphere coexistance recommendation will have to manually configure and maintain a list of TCP/IP ports used by difference instances of WAS. The current implementation assumes that only one instance of WAS will be on a physical machine therefore a hardcoded starting port for HTTP Transports is acceptable. However this does not allow for multiple instances to be maintained and increases the administration work for WebSphere.Problem conclusion With this fix, it is now possible to configure the "LastUsedPort" attribute on the Node via WSCP the same way any attribute can be accessed. EX: wscp> Node show /Node:myNode1/ {Name myNode1} {FullName /Node:myNode1/} {CurrentState Running}{DesiredState Running} {StartTime 1025038723374} {OsName {Windows 2000}} {HostName NT2} {HostSystemType x86} {ProcessId 1656}{InstallRoot {C:\WebSphere\AppServer}} {LastUsedPort 9082} wscp> Node modify /Node:myNode1/ -attribute {{LastUsedPort 9100}} (patch available for was4.0.2 and was4.0.3, code will integrate in PTF5)Temporary fix provided customer with packaged eFix, waiting for customer confi rmationComments This is working as the design in 4.0. In 3.5x, the HTTP server port is hardcoded to be 9080 and the user does not allow to change or configure a new port value for an application server. The design is changed in WAS 4.0. The default port for an HTTP transport is 9080 and the value will be incremented by 1 for each new transport created. The lastusedport value is stored in the Node table and the user is able to configure a different or add a new port through the admin console, wscp or XMLConfig. The new configured port value is stored in the EJBServer table and will not overwrite the lastusedport value in the Node table. We hardcoded the HTTP transport as 9079 and does not expose the new configured port value to avoid the port value conflict and easily tracking for the users whenever in single or multi-node environment. The design has been working since 4.0.1 and we do not think that it is necessary to change the existed behavior in the apar or ptf release because most of users/customers use to the behavior since 4.0.1. It is just like we hardcode the bootstrap port as 900 and lsdport as 9000. The customer can change the HTTP transport through the adminGUI or write a simple wscp script to set up the transport values as they need in creating the application servers.
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
SRLS
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ59624
IBM Group: Software Group
Modified date: Dec 24, 2002
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.