| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Microsoft Windows B31012-02 |
|
 Previous |
 Next |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.1.0) for Microsoft Windows B31012-02 |
|
Previous |
Next |
This chapter describes issues associated with Oracle Application Server Adapters. It includes the following topics:
Section 6.1, "Oracle Application Server Adapter for Files/FTP Issues and Workarounds"
Section 6.2, "Oracle Application Server Adapter for JMS Issues and Workarounds"
Section 6.3, "Oracle Application Server Adapter for AQ Issues and Workarounds"
Section 6.4, "Oracle Application Server Adapter for Database Issues and Workarounds"
This section describes the following issue and workaround:
If CorrelationSets are used with file adapter (starting with empty bpel project template), then the PropertyAliases get created in the partnerlink wsdl files. However, if you edit the adapter partnerlink, the propertyaliases are removed from the wsdl file, and this leads to compilation issues for the bpel project.
To overcome this issue you must edit the adapter partnerlinks files(wsdl files) manually instead of going through the wizard.
This section describes the following issues and workarounds:
Section 6.2.1, "JMS adapter in an XA scenario against AQ-JMS (OJMS)"
Section 6.2.2, "ESB Cannot Run JMS Adapter (OEMS JMS provider) in Non-Managed Mode"
Section 6.2.3, "Regression Stress - Dequeue Fails with AQJMSException in AQJMS Advanced Scenario"
You must use separate Resource Providers for inbound and outbound AQJMS Adapters:
You must set a new partnerlink property (BPEL) or endpoint property (ESB) called "cacheConnections" to false. If this is not specified, then the default value is true (which is the default in both 10.1.2 and 10.1.3).
You should use separate OJMS resource providers (defined J2EE_HOME/config/application.xml) for inbound and outbound JMS destinations (queues or topics) participating in the same global transaction.
JMS Adapter cannot use connection information from WSDL to run in non-managed mode. It reports missing connection factory.
Even in non-managed mode, some adapters have pre-requisites; you should not assume that non-managed equates no server configuration is required. For instance, the JMS Adapter requires a resource provider to be configured inapplication.xml and potentially data-sources.xml (if the resource provider refers to a data source). If these pre-requisites exist ahead of time, then non-managed mode would also work for ESB. Exact same issue pertains to BPEL as well. Note that this is applicable only for OEMS JMS provider.
Under heavy system load, that is, when the load for inbound and outbound for AQ JMS adapters is high, dequeue fails with an AQjmsException.
To address this issue, use the following workaround:
Create two separate physical connection pools (that is, use two separate (AQ) JMS resource providers). Each JMS WSDL (Enqueue and Dequeue) then points to a different JCA JNDI Connection Factory, which in turn would point to two separate JMS connection factories, each using one of the two resource providers, as shown in the following examples:
Enqueue WSDL
<jca:address location="eis/aqjms1" />
Dequeue WSDL
<jca:address location="eis/aqjms2" />
JmsAdapter/oc4j-ra.xml
<connector-factory location="eis/aqjms1" ... <config-property name="connectionFactoryLocation" value="java:comp/resource/aqjms1/QueueConnectionFactories/qcf"/> ... <connector-factory location="eis/aqjms2" ... <config-property name="connectionFactoryLocation" value="java:comp/resource/aqjms2/QueueConnectionFactories/qcf"/> ...
j2ee/home/config/application.xml
<resource-provider class="oracle.jms.OjmsContext" name="aqjms1"> <description>OJMS Context using thin JDBC</description> <property name="url"value="jdbc:oracle:thin:scott/tiger@localhost:1521:ORCL" /> <resource-provider class="oracle.jms.OjmsContext" name="aqjms2"> <description>OJMS Context using thin JDBC</description> <property name="url" value="jdbc:oracle:thin:scott/tiger@localhost:1521:ORCL" />
|
Note: Even when the scenario works fine under regression stress, you will still see theAQJMSException in the log. You can use this workaround to avoid this exception. |
When using Topics with OJMS (AQ based JMS), AQ JMS Topic hangs, and does not dequeue even though there are messages at topic.
The JMS adapter subscriber (inbound) WSDL should use a JCA connection factory (for example, eis/OJms/myConnectionFactory1) which uses an OJMS resource provider (for example, resprov1), which is based on a URL (for example, jdbc:oracle:thin:@host:1521:orcl).
The following list exemplifies the workaround mentioned in the preceding paragraph:
MyJmsSubsriber.wsdl
...
<service name="JmsSubscribe">
<port name="jmsSubscribe_pt" binding="tns:jmsSubscribe_binding">
<jca:address location="eis/OJms/myConnectionFactory1"/>
...
J2EE_HOME/application-deployments/default/JmsAdapter/oc4j-ra.xml
<connector-factory location="eis/OJms/myConnectionFactory1" connector-name="Jms Adapter"> <config-property name="connectionFactoryLocation" value="java:comp/resource/resprov1/QueueConnectionFactories/myQCF"/>
J2EE_HOME/config/application.xml
<orion-application ...
...
<resource-provider class="oracle.jms.OjmsContext" name="resprov1">
<property name="url" value="jdbc:oracle:thin:@host:1521:orcl" />
<property name="username" value="scott" />
<property name="password" value="tiger" />
</resource-provider>
This section describes the following issue and workaround:
When there are large number of messages (more than 100K) in an AQ queue, dequeuing in the AQ adapter can be very slow. The problem is a performance issue with the 10.x.x version of the database. However, the previous versions of the database work fine.
When you encounter this issue, run one of the following commands to generate statistics for the queue or topic table:
dbms_stats.gather_table_stats('JMSUSER', 'QTAB')
or
dbms_stats.gather_schema_stats('JMSUSER')
where QTAB is the Queue/Topic table and JMSUSER is the user/schema. Note that statistics should be refreshed every time a large number of rows are updated, inserted, or deleted.
This section describes the following issues and workarounds:
Section 6.4.1, "DB Adapter Wizard Shows Empty (Blank) Page After Creating DB Connection"
Section 6.4.2, "Faulted DBAdapter Instances Do Not Appear in BPEL Console"
After migration of 10.1.2.0.2 122.DBAdapter/InsertWithCatch (when you open in JDeveloper 10.1.3.1), if you open the project, and double-click the DB adapter partnerlink, then you will get a message stating that your UI connection is missing. After you create the UI connection, and click the Next button, you will get a blank page.
The issue here is that the Next button should be disabled, which in this case, isn't. The workaround is ensure a connection exists and is selected, and not to click the Next button otherwise.
Faulted DBAdapter instances do not appear in BPEL console because the BPEL auditing is tied to the JTA transaction, that is, auditing can only occur if the JTA transaction commits.
The faulted instance does not appear if a XA/JTA DBAdapter invoke fails, and the JTA transaction cannot (must not) be committed. This problem also occurs with server timeouts, where the JTA transaction is marked rollback only. However, in 10.1.3.1 DBAdapter is configured for JTA out of the box so this problem is now apparent all the time.
Report of success or failure has to be tied to JTA, but you cannot report failure and rollback the transaction at the same time. If the instance is successful you must audit through JTA, but if unsuccessful you theoretically cannot (you are writing as part of a transaction which can never commit.)
