Article Original Creation Date: 2012-06-05
Problem
The customer did setup a timer driven policy with in total an index range of 20.
With index range of 8 all works ok.
Checking the encore.log files did not reveal a error logged. ( added encore.log for time when modem was interrogated and when policy timed out )
Next day, I tried also with a comma separated list for index filter 4 ( instead of a range 1-20 ) 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20
for policy ‘wdw test portmapping 4’. The result was the same, policy timed out.
for policy ‘wdw test portmapping 4’. The result was the same, policy timed out.
Next I tried a comma separated list for index filter 4: having 1,2,3,4,5,6,7,8,9,10 (‘wdw test portmapping 5’)
Again the result was the same, policy ended in time out and no data stored in the table.
Again the result was the same, policy ended in time out and no data stored in the table.
I tried again with a comma separated list for index 4 : having 1,2,3,4,5,6,7,8 ((‘wdw test portmapping 6’)
This executed normally and the values were stored in database.
This executed normally and the values were stored in database.
Can you explain why there is a limitation on indexes or why the policy times out without error?
Environment
Solaris 10
Oracle 10
Weblogic 9.3
Cause
Checking the logs from several devices that timed out shows me the application tries to retrieve several times the same information in different snippets.
Engineering send me below answer:
There are two separate issues here, both long-standing bugs.
1) The system is supposed to request only 20 parameters at a time. In your case, there are 120 parameters to ask for, so it should make 6 requests of 20 each. Due to the bug, it is making the 6 requests, but not asking for the correct list each time. The conclusion that the repeating parameters are based on the port mapping index value is not correct. It has nothing to do with the index values, just the total number (you will see that not all 6 parameters for the first index is requested, after the initial request containing all of them).
2) As above, the system is supposed to break up the total list into smaller lists of 20. However, for exact multiples of 20, an extra empty list is being included in the list of lists. When this 7th empty list is processed, a null pointer exception results. You should be seeing this NPE in one of the app server logs immediately after the 6th GPV is returned. The NPE causes a fatal error for the action, which never returns a policy action response to the workflow engine, which is why the policy action timeout catches it.
2) As above, the system is supposed to break up the total list into smaller lists of 20. However, for exact multiples of 20, an extra empty list is being included in the list of lists. When this 7th empty list is processed, a null pointer exception results. You should be seeing this NPE in one of the app server logs immediately after the 6th GPV is returned. The NPE causes a fatal error for the action, which never returns a policy action response to the workflow engine, which is why the policy action timeout catches it.