Deepak Arora from our very own A-team wrote a white paper with the objective to provide the tools and an approach required to assist SOA administrators in choosing an optimal purging strategy and tool sets to best manage dehydration store requirements. The goal is to provide a methodology to profile the dehydration store usage (based on # incoming flow of BPEL processes, # outflow of BPEL processes, etc) and then use the current 10g purging toolkit to create a strategy that best fits the dehydration store usage profile.

This is the most common way to create an object in java.In This we will be using the new operator which will allocates the memory space and initialize the field with default value. Then it executes the code inside the specified constructor which normally re-writes the default values with the value inside the constructor.

MyObject object new MyObject();

2. Using Class.forName()

If we know the name of the class & if it has a public default constructor we can create an object in this way.

MyObject object (MyObject) Class.forName( com.demo.MyObject ).newInstance();

3. Using clone()

The clone() can be used to create a copy of an existing object. Object.clone() is a native method which translates into instructions for allocating the memory and copying the data.Even if you override the clone method then also you need to call the super.clone() method inside the overridden clone method. In this method a copy instruction is called and which copy the data from original object to clone object.

4. Using object deserialization

Object deserialization is nothing but creating an object from its serialized form. It will uses the ‘new’ operator internally and always calls the default constructor.

ObjectInputStream inStream new ObjectInputStream(anInputStream );

MyObject object (MyObject) inStream.readObject();

5. Using class loader

one more is through creation of object using classloader like

this.getClass().getClassLoader().loadClass( com.amar.myobject ).newInstance();

Oracle Application Server 10g Enterprise Edition – Version: 10.1.2.0.0 to 10.1.2.3.1
Information in this document applies to any platform.

OPMN and Process Monitoring:

OPMN ( Oracle Process monitoring and Notification services ) are a set of processes that manage mid-tier Application Server components like Oracle HTTP Server (Apache) and OC4J containers.
OPMN consists of  the Process Manager and the Notification Server.

( In Oracle 10g, OPMN manages all Application Server components except Oracle AS Metadata Repository and Application Server Control Console; it can be configured to manage Oracle AS Port Tunnel and custom processes because of its extensible design. )

Oracle Notification Server (ONS) is the transport mechanism for failure, recovery, startup and other related notifications between components in Oracle Application Server. It operates according to a publish-subscribe model: an Oracle AS component receives a notification of a certain type as per its subscription to ONS. When such a notification is published, ONS sends it to the appropriate subscribers.

Oracle Process Manager (PM) is the centralized process management mechanism in Oracle Application Server and is used to manage Oracle AS processes. It starts, stops, restarts and detects death of these processes. The Oracle AS processes that PM is configured to manage are specified in the opmn.xml file. The PM waits for a user command to start specific or all processes. When a specific or all processes are to be stopped, the PM receives a request as specified by the request parameters. OPMN is monitored by a shadow process that restarts upon request or after a catastrophic failure.
The PM uses ONS to:

*
detect that a process has completed initialization and is ready to receive requests
*
determine what ports are in use
*
obtain component specific runtime information

Four parameters determine the behavior of the Oracle Process Manager and Notification services process in managing the iAS middle tier comprising of OC4J instances and the Apache HTTP server. They are

a) restart-on-death
b) ping timeout
c) ping interval
d) reverse-ping timeout

The settings for these parameters need to be governed by the heap sizing of the OC4J container JVMs, the latencies involved with garbage collection algorithms and the response times of the HTTP server.

The way in which the parameters affect the functioning of OPMN is as follows :

By default, as in the schema definition file, opmn.xsd, the restart-on-death parameter takes a default BOOLEAN value of “TRUE” which means that OPMN’s mandate is to ping the managed processes ( OC4J instances and Apache ) at certain pre-defined intervals, monitor them for a response within a certain specified timeout period and retry the operation 3 times before concluding that the process is dead due to its non-responsive state and killing and restarting it to guarantee that the managed processes are up and able to service client requests on an ongoing basis – this is OPMN’s mandate in ensuring failover and availability of the processes it manages.
Oracle HTTP Server

There could be a variety of reasons for the non-responsiveness of the Apache server :

* due to a high load of concurrent requests competing for the web server’s attention
* because of timeouts between the various modules of Apache and the servers servicing client requests
* while it is in the middle of handling chunk data received from its modules
* when it is involved with dealing with persistent connections that have fully used up the number of servers
it can spawn, with many connections remaining in the CLOSE_WAIT state
* due to thrashing when NFS hiccups cause files that need to be served to be unavailable to it
* because of synchronization issues with the various mutexes that it needs to support for the proper
functioning of its modules.

In any such case, due to Apache’s unresponsiveness over the ping period, OPMN will kill and restart OHS as needed.
OC4J containers

In the case of the OC4J instances ( Oracle containers for J2EE ), OPMN follows similar logic to determine whether or not to kill and restart them. While the container is processing servlet or EJB logic within the JVM within which it runs, new objects get created in its heap memory area all the while.

When the garbage collection thread starts to run, it looks for objects that it can release to the heap memory pool based upon several algorithms that depend upon the kind of references the objects have to themselves. Since the collection is “generational”, i.e., objects having references are promoted to an older generation and presumed to have a longer lifetime, objects with weak references are candidates for “cleaning” up, and their occupied memory gets released to the global heap of the JVM.

In this way, memory is reclaimed back into the the heap memory pool and made available for use in the creation of newer objects. The forays made by the garbage collector to reclaim memory in the heap are governed by several algorithms and every such collection takes a finite amount of time during which no other work of application processing is possible. And when the collection is over the entire heap, the full GC consists of a mark/sweep/compact cycles that “mark” the memory to be reclaimed, “sweep” the memory into the corresponding generations and “compact” the holes created when the memory is reclaimed, in order as to create contiguous memory for future object creation.

These strategies consume more time, as to be expected, and can result in a delay in the container responding to an OPMN ping cycle. During such full GC scans, OPMN can and will kill and restart the container, causing it to lose the state of the application or request it was processing at that time.

Since full GC scans (referred to to as stop-the-world scans) can happen at any time during the lifetime of a request or an application, there is always the danger of OPMN killing a perfectly functioning container on the assumption that it was “hung” since it was “unresponsive”.
Heap memory settings for OC4J containers

These settings are made in the opmn.xml file in the <java-option> sections for each OC4J instance:

The settings for heap must include the -Xms ( for start heap memory ) and -Xmx ( for maximum heap memory ). Always use the “-server” option as the first option in the <java-option> sections, for Server HotSpot JVMs, best suited to long running JVMs in terms of performance. The recommended settings for the -Xmx value are 512MB as typical applications need that much of memory to avoid java.lang.OutOfMemoryError exceptions as seen from experience. Start with an -Xms value of 128MB to prevent side effects of “Too many files open” errors when this setting is higher, as garbage collection kicks in only later for higher -Xms values, resulting in open file handles not getting released by the GC.

<java-option>-server -Xms128M -Xmx512M

Thread pool sizing

In the server.xml file, set the thread-pool sizes as follows for optimum operation of the thread pool:

<global-thread-pool min=”40″ max=”40″ queue=”80″ keepAlive=”-1″/>

This sets the min and max thread-pool sizes to the same value and the keepAlive parameter to “-1″ – recommended for production environments, this will ensure that idle threads are never destroyed to allow for thread reuse without the overhead for new thread creation. The min, max and queue values can be left at the default as specified here.

Redundancy and load balancing

More than one OC4J instance can be started to accommodate the higher volume of concurrent requests that the container may need to handle. This is set through the “numProcs” parameter in the opmn.xml file and this parameter takes the value of 1 by default, to start a single OC4J instance. For multiple instances, the “numProcs” parameter can be adjusted to different values ( 2 for two instances, and so on ) and PM needs to be restarted with this value for the modules under its control. Very often, the applications that are being run may be process or memory intensive and may require one to adjust the value of the “numProcs” parameter to effect load-balancing via multiple instances.

Oracle Application Server 10g Enterprise Edition – Version: 10.1.2 to 10.1.2
Oracle Containers for J2EE – Version: 10.1.2 to 10.1.2

The following solution works for 10.1.2.x – it is based on the OPMN and OC4J documentation, despite some details are not covered in the manuals.

Solution for 10.1.3.x would be slightly different due to changes in OPMN and OC4J, and is not covered by this Note.

For 10.1.2.x

1. If the OC4J instance is running, stop it (opmnctl stopproc …)
2. Configure OC4J instance for HTTP Listening. There is a prepared http-web-site.xml file in the OC4J instance’s config directory, which has the definitions for listening to HTTP. Add it to server.xml in the following way:

<web-site default=”false” path=”./http-web-site.xml” />

Note: Leave the existing line of <web-site default=”true” path=”./default-web-site.xml” />
as it is, as it is required for AJP port assignment

3. Edit opmn.xml, and in the <process-type> section of the OC4J instance,
1. Add a setting like

<port id=”http” range=”8501-8900″ />

to select a range of ports for HTTP.
2. For the <process-set>, set the numprocs attribute to the number of processes that you want to run. Of course all port ranges need to be large enough so that each of the processes can have a distinct port of each type.

Hint: Use “opmnctl validate” to make sure your opmn.xml syntax is correct.

4. Now is a good time to run “dcmctl updateConfig” and “dcmctl updateConfig -ct opmn” to make the DCM repository aware of these config changes.
5. Use “opmnctl reload” to make OPMN reload the new settings from the opmn.xml file.
6. And last but not least start up the OC4J instance via “opmnctl startproc …”
7. And check the output of “opmnctl status -l”:

OC4J | OC4J_Custom | 10105 | Alive | 2102592122 | 64560 | 00:04:27 | http:8801,ajp:12506,rmi:12407,jms:12607
OC4J | OC4J_Custom | 10106 | Alive | 2102592123 | 64968 | 00:04:27 | http:8802,ajp:12507,rmi:12408,jms:12608
OC4J | OC4J_Custom | 10107 | Alive | 2102592124 | 75108 | 00:04:27 | http:8803,ajp:12508,rmi:12409,jms:12609

=> It reports the HTTP ports of each of the processes, and you can use them to access each of the processes directly from a browser.

Note: Do not try to remove the AJP ports. OPMN will fail when you try that, because it needs to have AJP and RMI configured, as OPMN uses those to monitor the OC4J instance/processes.

1. Remove the Metadata by running the below command, before please check iasconfig.xml

<ORACLE_HOME>/perl/1.5.2/MS-Win…/perl.exe <ORACLE_HOME>/bin/deconfig.pl

2.  De-Install the Product from Oracle Universal Installer and remove all the Oracle Application Server Instance trace from the machine.

The default domain was not set in the Apache configuration. When this occurs, only the host name is shown in the Login link and the domain is not included.

OracleAS Portal was configured with an incorrect host or port.

Action: Do one of the following:
Remove all such aliases from your Apache configuration.

Include the domain in the ServerName parameter.

Fix the Host in the IASInstance element and ListenPort in the WebCacheComponent element in iasconfig.xml and run ptlconfig -dad portal -site. The ptlconfig script and the iasconfig.xml file are normally located in the directory portal/conf under the OracleAS Portal and OracleAS Wireless middle-tier home.

Routing the request from one domain to another with in the application will leads to the open a new requests for each click.

This issue is named as CrossSiteScripting in IE8. IE8 providing blocking the applications which is using the CrossSiteScripting .

To resolve the above issues in applications, we need to sniff the IE8 with below solution:

1. We must have the machine where the application code one is deployed and the application code two machine in the same sub domain (domainx.com)
2. Set the following property in IE 8 security settings as the following:  Internet Options –> Security –> Custom Level [Internet]–> Enable “navigate windows and frames across different domains” setting (By default it is Disabled)
3. This will resolve the issue

————————————————————

Link: http://download.oracle.com/docs/cd/B10501_01/network.920/a96577/oid_java.htm

————————————————————————

f:\oracle\product\ias\soasuite\j2ee\oc4j_soa\application-developments\default\OracleASjms\oc4j-ra.xml

<connector-factory location=”OracleASjms/MyTCF” connector-name=”OracleASjms”>

<config-property name=”jndiLocation” value=”jms/TopicConnectionFactory”/>

<connection-pooling use=”private”>

<property name=”waitTimeout” value=”300″ />

<property name=”scheme” value=”fixed_wait” />

<property name=”maxConnections” value=”50″ />

<property name=”minConnections” value=”0″ />

</connection-pooling>

f:\oracle\product\ias\soasuite\j2ee\oc4j_soa\config\data-sources.xml

<connection-pool initial-limit=”10″ min-connections=”10″ max-connections=”100″ inactivity-timeout=”30″ max-connect-attempts=”10″ connection-retry-interval=”5″>

<connection-factory factory-class=”oracle.jdbc.pool.OracleDataSource” user=”oraesb” password=”->pwdforOraesb” url=”jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=tcp)(HOST=host1.test.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=testdb.test.com)))” commit-record-table-name=”"/>

</connection-pool>

<connection-pool initial-limit=”10″ min-connections=”10″ max-connections=”100″ inactivity-timeout=”30″ max-connect-attempts=”10″ connection-retry-interval=”5″>

<connection-factory factory-class=”oracle.jdbc.pool.OracleDataSource” user=”oraesb” password=”oraesb” url=”jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=tcp)(HOST=host1.test.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=testdb.test.com)))” commit-record-table-name=”"/>

</connection-pool>

<connection-pool initial-limit=”10″ min-connections=”10″ max-connections=”100″ inactivity-timeout=”30″ max-connect-attempts=”10″ connection-retry-interval=”5″>

<connection-factory factory-class=”oracle.jdbc.OracleDriver” user=”orabpel” password=”->pwForOrabpel” url=”jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=tcp)(HOST=host1.test.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=testdb.test.com)))” commit-record-table-name=”"/>

</connection-pool>

<connection-pool initial-limit=”5″ min-connections=”5″ num-cached-statements=”50″ validate-connection=”true”>

<connection-factory factory-class=”oracle.jdbc.pool.OracleDataSource” user=”scott” password=”tiger” url=”jdbc:oracle:thin:@//host1.test.com.com:1521/testdb.test.com” commit-record-table-name=”"/>

</connection-pool>

f:\oracle\product\ias\soasuite\j2ee\oc4j_soa\config\transaction-manager.xml

<?xml version = ’1.0′ encoding = ‘UTF-8′?> <transaction-manager xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=”http://xmlns.oracle.com/oracleas/schema/transaction-manager-10_0.xsd” transaction-timeout=”600″ max-concurrent-transactions=”-1″>

<commit-coordinator retry-count=”4″>

<middle-tier>

<log type=”none” location=”"/>

<recovery retry-interval=”300″ rlrc-purge-interval=”10″ rlrc-min-purge-size=”1000″/>

</middle-tier>

</commit-coordinator>

<events/>

</transaction-manager>

f:\oracle\product\ias\soasuite\integration\esb\config\esb_config.ini

# Cluster name

cluster_name=ESB

# Central OC4J or not

primary_oc4j=true

# JTA

xa_timeout=600

# JMS receive timeout (in seconds)

jms_receive_timeout=60

#BPEL system property

esbSystemForBPEL=BPELSystem

#Retry

InboundRetryCount = 3

InboundRetryInterval = 5

InboundRetryEnabled = true

OutboundRetryCount = 3

OutboundRetryInterval = 5

OutboundRetryEnabled = true