For a listing of bug fixes and enhancements included in
this release, please visit our bug database.
1.1 General Issues
Solaris and the random number generator: In Openwings
1.1, the use of java.util.Random in the DefaultUniqueIDGenerator
was replaced by calls to java.util.SecureRandom
to eliminate the rare occurrence of identical UniqueID instances.
Solaris 8 and Java 1.4.2 exhibit a problem when using the
SecureRandom class. This manifests itself in Openwings during
calls to the DefaultUniqueIDGenerator during
the creation of new processes. The SecureRandom
class makes calls to /dev/random which never
return. In general use, this behavior will manifest as an
apparent lockup of the Openwings Container, requiring a
system reboot to recover.
This is a problem specifically with Java and Solaris. We
work around it by providing a system property. If you experience
these problems, edit the ${OW_HOME}/openwings-${VERSION}/policies/properties.txt
file, and modify the following property setting from:
net.openwings.identity.implementation=com.gd.openwings.identity.DefaultUniqueIDGenerator
to:
net.openwings.identity.implementation=com.gd.openwings.identity.FallbackUniqueIDGenerator
and restart the system.
Windows and the random number generator: It is possible
that the system could create multiple identical UniqueIDs
(for example, when creating services or processes). In practice
this is quite rare, and only occurs if the system is rapidly
creating a large number of IDs in sequence. This is because
the random number generator depends on the system clock,
which suffers from a lack of precision (only accurate to
1/3 of a ms).
Multi-homed hosts and Openwings: Past releases of
Openwings have been configured by default to use the Network
Interface Card (NIC) that is associated with the hostname
returned by the `hostname` system call on hosts
with multiple NICs. Openwings 1.1 allows the administrator
to choose which hostname to use by default. A property has
been added to the ${OW_HOME}/openwings-${VERSION}/policies/properties.txt
file that allows the administrator to define the hostname
associated with the NIC of choice. The property is:
java.rmi.server.hostname=<hostname>
In order for this to work properly, DNS (or NIS+) must
be properly configured to provide Name Service and routing
information for the network in question.
1.0 General Issues
Beginning with Openwings 1.0, Windows 98 (and all Windows
flavors not based on the NT architecture) are no longer
supported platforms. If you attempt to run Openwings on
these platforms, you may need to take additional steps.
For example, if the static installer fails to run automatically
at installation time, you'll need to reboot and then run
the static installer manually (owinstall.bat -static).
Secure vs. Unsecure Installation: Openwings can
be installed in "unsecure" mode, which is similar
in functionality to older releases. "Secure" mode
is a new option, which is discussed in further detail in
the Security
Introduction tutorial trail. No matter which you select,
you can also choose between runtime and development installs
as detailed
here.
0.9.2 General Issues
Renaming of "PropertyFile" property: The property
net.openwings.context.PropertyFile has been renamed net.openwings.identity.PropertyFile
to reflect that this property is used by the class net.openwings.identity.PropertyInitializer.
You must change this property in existing component ICDs
for them to work with 0.9.2 and later.
Security policies required for all components: For
the Code Security feature included in 0.9.2 and later, the
Install Service, Container Manager and Container implementations
have been modified to enforce security policies on all processes.
Components without security policies may fail in unexpected
ways. Please visit the Code Security trail (see the Openwings
tutorial) to learn how to create a security policy for
your component
Static installer: For the Code Security feature
included in 0.9.2 and later, the Install Service now supports
a static install mode. The static installer is invoked when
Openwings is installed to resolve dependencies within the
static components in the Openwings implementation (including
openwings, jini, and jakarta-tomcat). After installing Openwings,
please check the directory ${OW_HOME}/openwings-${VERSION}/data.
If the directory contains several .xml and .policy files,
the static installer has run correctly. If not, you will
need to run the static installer as described in the manual
install instructions.
Compatibility of core services: because of changes
to the RMI connector generator, core services such as ContainerManager,
Installer running on Openwings 0.9.2 and later platforms
will not be visible on platforms running older versions
of Openwings (and vice-versa).
0.9 General Issues
Compatibility of InstallableComponentDescriptorPolicy.xml
files: The classes net.openwings.identity.ComponentDescriptor,
net.openwings.identity.UniqueID, and net.openwings.install.InstallableComponentDescriptor
have changed slightly since the 0.8.2 release. Old ICDs
will not be readable by the ICD editor unless a couple of
text substitutions are made to the xml files. Instead of
the headache of conversions, we strongly suggest starting
over in building ICDs for this release. One reason in favor
of this approach is the improvements we've made to the wizard
that have better default settings for classpath and codebase.
Compatibility of core services: because of changes
to the RMI connector generator, core services such as ContainerManager,
Installer running on Openwings 0.8.* platforms will not
be visible on Openwings 0.9 platforms (and vice versa).
Multi-user Systems
If Openwings is installed on a multi-user system, we strongly
suggest installing under a separate user account and starting
the Openwings core using that login. Starting the Openwings
core starts a copy of Sun's Jini Lookup Service (Reggie),
the default discovery mechanism used in the Openwings beta
release. Reggie creates its own log files with default permissions.
If multiple users attempt to start the openwings core, Reggie
will fail to start since these users will not have permission
to overwrite the log files.
Changing the Web Server
Openwings is configured to use the Jakarta Tomcat webserver
in order to serve downloadable jar files (for connectors,
user interfaces, etc.) from port 8080. Should you wish to
use a different webserver (or switch Tomcat to a different
port), you will need to perform the following steps:
- Stop the Openwings container manager (
ow.bat
or ow.csh) for this platform.
- Edit the file ${OW_HOME}/openwings-${VERSION}/policies/properties.txt.
Find the property "net.openwings.http.root"
and note the original value. This property is used by
the Openwings installer as the base location for copying
downloadable jar files. Change the value of the property
"net.openwings.http.root" to point to the root
directory under your webserver where you wish these downloadable
files to be copied.
- Also in properties.txt, make sure the value of "net.openwings.port"
is set to the desired port number used by your webserver.
- The original value of the property "net.openwings.http.root"
denotes a directory which should contain a directory named
"install". Copy this entire directory from the
old location to the new location you chose in the previous
step.
- Re run the Openwings installer in static mode (
owinstall.bat
-static or owinstall.csh -static).
- Restart the Container Manager (
ow.bat or
ow.csh).
System Performance Monitoring
The purpose of this section is to capture potentially useful
information concerning the System Performance monitoring
capabilities within the container manager.
Common concerns
- All the performance monitoring is tightly coupled into
the environment, and has been tested only on our testbed.
As other people experiment, it is anticipated that we
will find discrepancies and conditions that do not work.
- 32-bit numbers: most, if not all platforms have potential
concerns surrounding memory/swap sizes in excess of 2GB.
- All network monitoring is based on standard Ethernet
NICs. If someone uses some unique/other adapter type (e.g.,
PPP over dialup), the network monitoring will not capture
that.
Windows Platforms
- Current State/Design
For Windows-based platforms, a native interface to a .dll
(owPerfMon.dll) is used to gather the peformance data.
The current DLL implementation for Wintel platforms is
broken into 4 pieces: a common portion, Windows 9x (95/98/Me),
Windows NT, and Windows 2000.
Windows uses the registry (or pseudo-registry to collect
performance data). Unfortunately, what data is stored
where is highly platform-specific. See references below
for more information.
- Assumptions
- Windows 9x - Assumed single processor (wouldn't
help to have two anyway).
- Windows 9x - Assumed single 10MB network connection.
- Windows 9x - Needs special Network Monitoring Driver
to gather network performance info. Check the references
below, or search for netmon.exe or nmagent.exe on
MSDN or Microsoft Technet.
- Windows NT - Needs special Network Monitoring Driver
to gather network performance info. This is included
with Windows NT.
- Issues/Concerns/Limitations
- The software was not tested on Windows ME.
- The software was not tested on 64-bit Windows platforms
(I don't expect it to work here, per some of Microsoft's
documentation)
- There is no simple/standard way to find out the
network bandwidth under Win9x.
- References
- Lessons Learned and other random thoughts
- Microsoft moves their information around frequently,
so watch out!
- Setting up the Network monitor (follow directions
above for download):
On the Network Monitor Agent host
computer:
- Install the Network Monitor
Agent (in Control Panel, click Network, click
Services, click Add, and then click Network Monitor
Agent).
- In Control Panel, click Services,
click Network Monitor Agent, and then click Start.
(If you want the Network Monitor Agent to start
when the computer starts, click Startup, and then
click Automatic.)
Unix Platforms
There are a lot of Linux and BSD flavors (including Mac
OS X) out there. Depending on which you use, the performance
monitoring may need a separate implementation of the performance
plugin in order to work. The setting is controlled by
the file $OW_HOME/openwings-${VERSION}/policies/ContainerManagerPolicy.xml.
For example, the line below configures the Openwings Container
Manager to use our provided Solaris performance monitor:
platformPerformanceImplementation="com.gd.openwings.container.manager.SolarisPerformance"
You might try using the Solaris performance monitor just
to see if it works -- it uses some pretty standard system
calls like df. You can also write your own performance
monitor and set the policy to use it. The interface for
the performance monitor can
be found here.
