In this post, I am going to list of some of the problems
which I could remember; I have faced during SOA Suite 11g to SOA Suite 12c
migration for one the recent project which I have completed.
Problem1: 'jca.retry.count’ error
While running some of the composite, transaction was getting
rolled back with below error message –
Cannot parse JCA binding
retry property 'jca.retry.count', value '0' due to: Value of JCA binding retry
property
'jca.retry.count' must
be a positive number: Cannot parse JCA binding retry property
'jca.retry.count', value '0' due to:
Value of JCA binding
retry property 'jca.retry.count' must be a positive number</summary>
,code=<code>oracle.fabric.common.FabricException</code>
,detail=<detail>oracle.fabric.common.FabricException:
javax.resource.ResourceException: Cannot parse JCA binding
retry property
'jca.retry.count', value '0' due to: Value of JCA binding retry property
'jca.retry.count' must be a positive
number: Cannot parse JCA
binding retry property 'jca.retry.count', value '0' due to: Value of JCA
binding retry property
'jca.retry.count' must
be a positive number
at
oracle.integration.platform.blocks.event.jms2.EdnBus12c.publish(EdnBus12c.java:1438
Solution 1:
This error was coming because ‘0’ was set for “NumberofRetry”
located at this path
We have modified
soainfrastructure>>
SOA
Administration>> common properties>> More SOA Advance Configuration
Properties >> Application
Defined Beans >> oracle.as.soainfra.config>>EDNConfig>>edn
I believe some internal changes been made for EDN delivery
retry mechanism. Earlier as part of 11g, we were able to set “NumberOfRetry=0”
but when we carried forward same value for SOA Suite 12c then composite start
failing JCA error as listed above.
To fix this error we just change “NumberOfRetry =1” or any
positive number up to 5.
Note: Setting number of “NumberOfRetry” =1 does not retry
failed JCA transaction automatically.
Refer this document for detailed understanding about
different value of NumberOfRetry and its impact.
Problem 2: ORA01400: cannot insert NULL into ("TST01_SOAINFRA"."AUDIT_DETAILS"."CI_PARTITION_DATE")
While running composite in test environment, we were getting
below error message.
ORA01400:
cannot insert NULL
into ("TST01_SOAINFRA"."AUDIT_DETAILS"
org.eclipse.persistence.exceptions.DatabaseException
Internal Exception:
java.sql.SQLIntegrityConstraintViolationException: ORA01400:
cannot insert NULL
into("TST01_SOAINFRA"."AUDIT_DETAILS"."CI_PARTITION_DATE")
Error Code: 1400
Call: INSERT INTO
AUDIT_DETAILS (CIKEY, DETAIL_ID, BIN, BIN_CSIZE, BIN_USIZE, DOC_REF, FLOW_ID,
CI_PARTITION_DATE,
SCA_PARTITION_ID)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
bind => [9
parameters bound]
Query:
InsertObjectQuery(AuditDetails flowId:
650233
componentId: 1415333
detailId: 1055735
docRef: null
binUsize: 0
binCsize: 0
partitionDate: null)
Solution 2:
This error was related to “CI_PARTITION_DATE” column value
inside “AUDIT_DETAILS” table. This error was coming specific to TEST
environment. Later we find out this was related to “Audit Level” configuration
which we can set at this PATH SOA-Infra>>SOA-Infrastructure>>SOA
Administration>> Common Properties >> Audit Level to “Development”
value.
This “Audit Level” property has two possible values a)
Production and b) Development. In both cases, it does different level of
logging. It’s obvious to understand that when we use “Audit Level =
Development” , it does more extensive logging using “Audit_Details” table and
was throwing above error.
The temporary fix of this error to change “Audit
Level = Off/Production”, in this case error won’t get generated.
The permanent fix we got from Oracle after raising the SR.
Oracle advised to install PATCH 24794863 which fixed this issue permanently.
Problem 3: Composite aka BPEL Code fixes
“bpel.config.inMemoryOptimization” and “bpel.config.transaction”
properties were causing unexpected behavior while BPEL execution.
Solution 3:
The existing BPEL code where utilizing above 2 properties,
but in 12c SOA Suite environment the BPEL containing above properties were causing
issues while BPEL execution, transaction were getting stuck and were getting
rolledback as well.
Later, after digging around a lot we came to know that these
property were causing the issue, though these property are well supported in
12c as per Oracle comment.
Since these property does not have any significant impact on
BPEL execution, to fix this problem we simply removed these properties from
composite.xml.
Before
After
Read below links, in case need
detail understanding about these two properties behavior.
Problem 4: Non-blocking Invoke Issue
This issue
also related to some of composite aka BPEL process. BPEL 11g offer execution of
parallel flow using “nonBlockingInvoke” BPEL Partner link property. However,
existing composite having parallel flow was getting stuck while execution.
Audit trail was showing only first branch execution, later it didn’t do
anything, Instance just get stuck.
Solution 4:
In 11g
threading model was having three different threading configuration Dispatcher
Invoke, Dispatcher Engine, and Dispatcher System Threads respectively wherein
we can specify how much treads count each category of threads required.
However, In
SOA12c weblogic has changed its threading model completely. Now, instead of
just 3 threading category, we have many work manager created to control thread
count for various purpose. One of the work manager “default_dspNonBlock”
also been created to handle parallel flow execution. This work manager has min
constraint “default_dspNonBlock_minThreads_1”
defined having default value 1, as result only thread can execute despite
having parallel flow activity inside BPEL code.
To fix this problem we need to increase the count of
min thread constraint “default_dspNonBlock_minThreads_1”
default value to some higher value e.g. 5
Problem 5: ORA-00001: unique constraint (TST01_SOAINFRA.SCA_FLOW_INSTANCE_PK) violated
Once we converted the SOA Suite 11g BPEL code to SOA
Suite 12c format and deployed into SOA 12c environment. The very first error we
faced is the below error. The impact of this error was every single BPEL
composite instance was getting rolled back.
Internal
Exception: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique
constraint (TST01_SOAINFRA.SCA_FLOW_INSTANCE_PK) violated
Solution 5:
The above error was bug in SOA Suite 12c and Oracle
has already released the patch 21571205 for this error.
However, the worse part of that was this patch was available only 12.1.3. version while in our environment we were running 12.2.1.1.0 and when I tried applying this patch to this version then optach utility complain about version mismatch of SOA Suite as result I couldn’t apply this patch using OPATCH utility.
This problem was like show stopper as none of the BPEL process could run, I started digging around inside content of this PATCH and was able to apply this patch manually without OPATCH utility.
However, the worse part of that was this patch was available only 12.1.3. version while in our environment we were running 12.2.1.1.0 and when I tried applying this patch to this version then optach utility complain about version mismatch of SOA Suite as result I couldn’t apply this patch using OPATCH utility.
This problem was like show stopper as none of the BPEL process could run, I started digging around inside content of this PATCH and was able to apply this patch manually without OPATCH utility.
Fortunately, this patch was not big patch and just
updating only one jar file few classes. Most of the Oracle patches comes with actions.xml
file which list out what are the jar files getting updated with which classes.
After looking inside content of this file, I download tracking-fabric.jar locally, unjar it, replaced all class file
given inside actions.xml file, packed the jar again and copied over the same
location and restarted the SOA Server which fix the problem.
No comments:
Post a Comment