Borland Deployment Platform 6.0 Release Notes
This release note contains information specific to the Borland Deployment
Platform 6.0 release. This release of the Borland Deployment Platform 6.0
addresses most of the customer-reported problems and includes the value-added
features set.
This release note contains the following sections:
Borland Deployment Platform Products
The Borland Deployment Platform includes three products:
-
Borland Deployment Op-Center
-
Borland Enterprise Server
- Borland Janeva (not covered in this Release Note.
See http://www.borland.com/devsupport/janeva/relnotes/6_0.html for
Janeva Release Notes.)
Borland Deployment Op-Center
This is the premier release of Borland Deployment Op-Center, a product that
provides deployment monitoring, management and visualization to ensure the
availability of mission critical applications. Major features include:
- Deployment Modeling
BDOC allows you to model your deployment.
You can group resources, set start and stop orders within grouped resources
and create failover groups of resources.
- Status Monitoring and Visualization
Displays status of full
system at a single glance. Displays status of modeled resources, propagates
status within group contexts, and permits easy navigation through your managed
system.
- Flexible Configuration
Allows configuration of single and
multi-host (distributed) systems. XML-based configuration makes it easy to
follow application life-cycle (Dev - QA - Production).
- Multiple Managed Resource Categories. Managed resources include:
- Processes (Java processes, native executables, servers, user-defined
processes)
- VisiBroker objects
- Web pages
- Web services
- Supports definition of start, stop and ping strategies for all resource
types
- Automatic Recovery Resources can be configured to be restarted
automatically after failure - no human intervention required
- Extensibility of Core Management System
Powerful scripting
engine based upon JavaScript allows remote management of all resources.
Borland Enterprise Server 6.0
BES 6.0 new features include:
- New generation IIOP Connector:
- Added support for statically defined clusters that can span ORB
domains
(i.e. corbaloc naming scheme as well as osagent naming scheme).
- Supports HTTP 1.1 chunking.
- Improved bi-directional large data handling in non-HTTP 1.1 chunking
scenarios.
- Binary posted data support added.
- Significant performance and scalability enhancements.
- The EJB Container has been significantly performance tuned with focus on
Entity Beans using CMP.
- The major contributor is the removal of CORBA style stub generation for
Entity bean local interfaces that leverages Java Dynamic Proxies. This and
some internal changes to the handling of primary keys in the EJB Container
show very significant improvements in entity bean access times.
- At the CMP persistence manager level there are additional tuning options
to delegate cascade deletes to the database's referential integrity rules or
triggers, extensions to EJB-QL, caching of auto generated primary key
blocks, etc. Please refer to the documentation for details.
- New option to timeout data cached in entity beans that have exclusive
access to the database (Option A)
- Value added CMP features
- Dynamic Queries support
- enhanced archive verification for making sure that CMP configuration in
the deployment descriptor is OK, which saves a lot of time and effort
compared to finding the problems at runtime
- Added support for arrays and char, Character as valid data types for CMP
field
- Auto Primary Key generation flags have alternate simpler forms and the
provision to use named sequence tables
- Tri level ejb.cacheCreate flag and new property to check existence
before create
- Another area that has been improved a lot in performance and features is
MDBs and messaging in general. Container mediated JMS messaging now benefits
from JMS connection, session and other resource pooling leading to enhanced
performance and scalability. In MDBs users now have options to configure the
handling of redelivered messages (avoiding poison messages).
- BES6 introduces complete JMS provider pluggability. BES5 allowed runtime
pluggability i.e. the runtime used standard APIs to integrate with any
compliant JMS product (retaining all MDB and transactional features). In BES6
the appserver has the additional architecture to integrate configuration of
JMS Admin objects like Connection Factories and service management into the
BES tool and admin layers.
- The default JMS provider bundled with BES6 is Tibco. Unlike BES5, SonicMQ
is no longer bundled. TibcoJMS is a high-end, enterprise-grade JMS provider, a
robust and proven implementation of the JMS 1.0.2 standard required by J2EE
1.3. BES 6 is certified to work with SonicMQ 5 and Tibco JMS 3.11. As stated
above BES is designed to work with any CTS compliant JMS product that
also implements the JMS 1.0.x chapter 8 APIs. This is much like how we certify
and support JDBC drivers.
- UDDI Server added to available partition services.
- Partitions are no longer rooted under a server; their footprint can exist
at any location.
- Agent and partition logging now based on log4j.
- Management Console includes many new statistical panels for the partition,
its services, and the applications it is hosting.
- Ant tasks have been added to the BES Ant environment to allow direct use
of IASTOOL commands, improving ANT's integration with Borland Enterprise
Server.
- Technology Preview of a Weblogic(R) Server to BES application migrator
utility that automates conversion of deployment descriptors and configuration
data so that the app is almost immediately deployable in BES. Please look
under <BES>/migrator
BES now based upon BDOC Management Architecture
BES is now based
upon the new BDOC management architecture. Therefore, all the benefits of this
architecture are now realized for BES server instances. For BES this means:
- Much more flexible configuration of server instances
- Automated recovery of failed processes
- Aggregation of status of BES components
It is important to note that many familiar BES characteristics have changed
subtly. In particular:
- The IAS agent process has been replaced by the new SCU agent process
(Borland Management Agent in the start menu). Stopping an SCU will NOT stop
BES partitions and services as was the case with IAS. To stop BES partitions
and services, you must stop the configuration they reside in before stopping
the SCU.
- BES server instances are now really BDOC configurations. A BDOC
configuration can contain any combination of managed objects. Any BDOC
configuration that contains a Partition can be considered to be a BES server.
The BES installer will optionally install an example BES configuration called
'j2eeSample' that is a classic BES server with three example partitions. If
you want to create a BES Server configuration that is nearly identical to the
old 5.2.1 BES Server, right-click on 'Configurations' and select 'New
Configuration...', and from the cascading menu, select 'bes' and then
'classic'.
- The SCU provides an automated process recovery function. Partitions or
other services that fail will automatically be restarted by the SCU.
- Because of this auto-recovery, to stop an individual component of a BES
Server configuration (partition, service, etc), you must first disable active
management, and then stop it. To disable active management, right click on the
component's node in the Console tree, and uncheck 'Actively managed'. As long
as any managed object is 'Actively Managed', it will be restarted by the SCU
when stopped (or when it fails).
- Partition command line usage has changed. Now typically one will invoke
"partition -path <partition root>". See "Partitions" in the Developers
Guide for full usage.
- Partition configuration is now centered in a partition.xml configuration
file. See "partition.xml reference" in the Developers Guide for details.
- Default logging configuration now writes to log4j XML files.
BES 6.0 VisiBroker Edition Release Notes
Click here for BES 6.0 VisiBroker Edition Release Notes (Windows
and Solaris)
Click here for BES 6.0 VisiBroker Edition Release Notes (HP-UX on
PA-RISC and IA, AIX, SuSE on x86, Red Hat on x86 and IA, Windows on IA and
Windows-BCB)
Click here for BES 6.0 VisiBroker Edition Release Notes (SLES 8 on
zSeries)
Click here for instructions on migrating secure VB application from
5.x to 6.0.
Platform Information
Supported platforms for this version of Borland Enterprise Server is
available at:
for visibroker edition, http://techpubs.borland.com/am/bes/platforms/60xplatformvbe.htm
for
appserver edition, http://techpubs.borland.com/am/bes/platforms/60xplatformase.htm
Installation Instructions
For installation instructions on other platforms, check the updates on the
main Tech Pubs page: http://www.borland.com/techpubs/bes
Important note on licensing:
BES and Op-Center MUST be licensed and registered before they will run -
there is no grace period. See http://www.borland.com/devsupport/bes/faq/6.0/licensing/index.html
for instructions on how to license your product.
Borland Enterprise Server Known Issues
- Compiling examples which use iastool on Linux may fail with Signal 11. GUI
tools dump core on exit. There is a known issue in the Linux C libraries
affecting Java applications which call System.exit(x). This is the recommended
practice for GUI applications. iastool and Console both use this method to
exit the VM. This problem is resolved in a later version of the C libraries.
Please see http://java.sun.com/j2se/1.4.1/relnotes.html
for more information. The suggested workaround is to edit the makefile to
ignore the failing command. Since the necessary work has been accomplished by
the time the tool exits, this is not a serious problem. (Case ID: 40159,
40138)
- The specification of a localhost for Tibco JMS in a partition's
configuration file must be consistent with the specification of hostname in a
dar file (jndi-definitions) file. For example if localhost name is "myhost",
if you specify "localhost:7222" in jndi-definition file you must also specify
"localhost:7222" for the Tibco managed object in the configuration file.
Similarly if you specify "myhost:7222" in the jndi-definitions file you must
also specify "myhost:7222" in the configuration file. (Case ID: 41633)
- For deployment situations where transaction manager is run as an external
process, VBJ thread dispatch pool size [threadMax limit] should be set to high
value to allow transaction synchronization callback threads to enter the VM
under high transaction concurrency. If there are as many concurrent
transactions in the partition, as the VBJ thread max of the partition then
synchronization callbacks that need to happen as part of the transaction
commit process, can't happen. In other words, a situation can happen where all
the threads in the partition are trying to call commit(), and hence wait on
the transaction service to finish the commit process, and transaction service
is waiting on the partition process to allow synchronization callback threads
to enter the VM. Due to this cyclic dependency the partition process will
appear to hang. As mentioned, the situation may only happen when the
transaction service is configured to run as an out-of-partition process, and
the partition has small value for VBJ threadMax. Usually it is rare to have
out of process transaction service, but should that be a requirement, the
situation can easily be avoided by keeping the partition's VBJ threadMax at a
high value or by keeping the threadMax un-bounded. We should know that VBJ
creates only as many threads as are necessary to meet the concurrency, so
keeping the threadMax un-limited doesn't mean there will be too many threads .
(Case ID: 40300) When OTS is used as the external transaction manager, it must
also have its thread dispatch pool size configured with a high value for
applications involving high transaction concurrency. This can be achieved
using VisiBroker property :
vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMax Set this property to 50 or
100, depending on the expected concurrency level, in OTS related
vbroker.properties file specified through -DORBStorage parameter. (Case ID
41605)
- With the new jdk (1.4.2_0x), it is observed that a J2EE archive like
ejb-jar built on windows was able to open on Solaris using DDEditor. But the
vice versa is not true, ie., the jar built on Solaris with the new jdk was
unable to open on windows using DDEditor. Similarly, there is one more
observation, the jar built using JBuilder on windows platform was unable to
open on solaris platform using DDEditor. The problem seems to be due to an
incompatibility between the jar files produced by the jar command on Solaris
and Windows. This appears to be a JDK bug (Case ID 39631)
- The JBuilder project files for EJB examples shipped with BES 6.0 will work
with JBuilderX and not with earlier release(s) of JBuilder.
- There seems to be a concurrency issue in SonicMQ 5.0. Under high load ie
when many concurrent threads in a JMS client try to send messages, SonicMQ
throws an exception "javax.jms.JMSException: java.net.ConnectException:
Connection refused: connect:localhost:2506". The problem can be reproduced in
a standalone client outside of BES. It seems to occur when the number of
connections required by Sonic client exceeds the current number of available
connections. In our setup if we ran the client with 21 threads specified, the
exception occurs. However, if you quit that client and wait for all messages
to be consumed from the queue and then rerun the same client with 21 threads
it will work without any reported exception. The same is true if you specify
30 threads. The first run of the client produces the exception but subsequent
runs generate no exception (Both BES partition and SonicMQ should not be
shutdown between runs). (Case ID : 41376). A case (W311114101) has been filed
with Sonic support. Please contact Sonic support for more details, current
workaround is to have SonicMQ with large number or unlimited connections.
- There is a known issue in the database level cascade delete support which
is only relevant for the "Exclusive" (option-A) commit mode. Please note that
the default commit mode in BES is "Shared" (option B) . The symptom of the
problem is the unexpected occurrence of "javax.ejb.ObjectNotFoundException" in
situations where a transaction involves large number of entity beans. The
workaround is to either use the "Shared" commit mode or to simply increase the
value of the entity property called ejb.maxBeansInTransactions or disable
transaction cache compaction by setting this property to zero. (Case ID :
41269)
- The JBuilder project for the ejb/basic/order example has an absolute path
name in it. Please perform the following steps:
- Use a text editor to open the <BES Install
Root>/examples/ejb/basic/order/jb/order.jpx
- Replace the following line:
<property category="archiving"
name="overrideManifestPath" value="Y%|/EJB/examples/basic/order/META-INF/MA
NIFEST.MF"/>
with line:
<property category="archiving"
name="overrideManifestPath" value="../META-INF/MANIFEST.MF"/>
- Save and exit
- When creating an Apache managed object, the managed object name must NOT
contain any spaces. If spaces are included in the managed object name, e.g.
'Apache Web Server', then Apache will fail to start.
- When deploying a DAR from a Windows console to a Solaris 64 server, a
CORBA.TRANSIENT error sometimes occurs, and the DAR is not loaded. In this
case, the DAR does get deployed, but to load it you must restart the
partition.
- The default security profile shipped is not ssl-enabled. If your partition
requires secure transport (EJB container sometimes does), then change the
security profile for your partition to the 'ssl_enabled' profile. Right-click
on partition, select 'Properties' command, select 'Security' tab, and change
the profile in the dropdown.
- Compiling JSPs using IASTOOL consumes large amounts of memory, and can
exhaust a system's virtual memory in many cases. An 'out of memory' exception
will be thrown in this case. For example, compiling JSPs in a WAR with 370
JSPs may use as much as 1.5GB of memory. There are two workarounds:
- Increase the size of the virtual memory on your system.
- Break up the JSPs into several WARs to reduce the memory requirement per
WAR.
- Editing, with DDEditor/EJB Designer, an EJB jar that does not have borland
proprietary deployment descriptor file (ejb-borland.xml) will create the
proprietary file, but will include some extraneous information in that file.
This jar will deploy and function correctly.
- Dump stack to log function should NOT be used on Linux Red Hat Itanium.
This function is accessible on the right-click menu of the Partition.
Executing this function will not cause a stack trace to be dumped, and will
prevent the Partition from being stopped normally.
Borland Deployment Op-Center Known Issues
- Confused managed-object states will be reported if you accidently start a
second SCU on the same machine configured as a local-hub or slave-agent.
- The SCU will be unable to stop a JDatastore server as a managed-object
process on Unix or Linux platforms unless it is started '-ui none' option. See
the Petstore cluster for an example.
- To allow the SCU to manage the IIS you must set the IISAdmin and WWW
services to have Startup Type = Manual. Use the Windows management console to
do this. Also be sure all the Recovery actions are 'Take No Action'.
- If you will be using the Janeva Petshop web site with the Petstore cluster
you will have to disable security in the petstore security profile.
- The Petstore cluster template requires a Op-Center license to run.
Known Issues common to BES and Op-Center
- License files can become corrupted if not licensing if not configured
properly. This is most likely when deploying VB applications.
If a licensed component is configured to access a license file on another
system (via a network mounted drive, e.g.), the following error will be
reported:
Cannot start: Borland Enterprise Server License error[1023]: Sanctuary
Initiation Error :License storage {0} does not apply to current user. Please
register your Borland product(s).
If this occurs, the licence files will be marked as unusable. You must
re-register that license to activate it again.
As a precaution, after registering your product, you may save a copy of the
<install dir>/var/borland.lic and borland.pkg files to another location.
Should the license file corruption occur again, licensing can be restored by
simply copying these files to the <install dir>\var folder.
- Deleting a license in the License Manager GUI does not fully delete a
network license (a license that uses a license server).
In the License Manager GUI (available in the Console via the Tools/License
Manager menu command, or on command line: <install dir>/bin/lmadm -r
info), you can right-click on a license and delete it. However, this does not
fully delete the license. To delete a network-nased license, you must manually
delete the regxxx.txt file and/or the concurrent_xxxx.slip file in the
<install dir>/license folder. Deletion of node-locked licenses does not
have this problem.
- On RedHat Linux (Pentium), the Installer, when calculating available disk
space, displays the following:
Disk Space Information (for Installation Target):
Required: 605,149,820 bytes
Available: Error!
You should check your available disk space manually at this point. If you
have sufficient disk space, installation will proceed normally.
- On Windows and RedHad Linux on Itanium, and RedHat Linux on Pentium, the
Installer will complete with warnings, because it is unable to succesfully
check free disk space (see above issue).
In this case, the resultant install log will contain a warning:
<action name="Check Disk Space" status="warning">
This warning can be ignored.
- On Linux systems, a fully qualified domain name and IP address needs to be
the first entry in the "hosts" file.
When running the BES Server on Linux, the Management Console and iastool
are sometimes unable to discover that server when run from a different system.
This is because the default Linux hosts file has only the loopback entry
(127.0.0.1).
In order to correct this, you must add an entry for the local host. For
example, on a machine named mylinux that is called mylinux.work.mydomain.com
at 172.1.1.1, the following must be added to the hosts file and must be the
first entry in that file:
172.1.1.1 mylinux.work.mydomain.com
mylinux
Additional copyright info
jUDDI Open Source Project Copyright
Copyright (c) 2003, Steve Viens and contributors. All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
- Neither name of Steve Viens nor the names of any jUDDI contributors may be
used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Made in Borland © 2003 Borland Software Corporation. All rights
reserved.