I would recommend starting the following:
1. Regenerate all failing modules using the compile_all=yes option. Do not copy FMX, MMX, PLX files from one machine to another. Be sure to generate them on the machine where they will be run.
2. If load balancing is used, ensure that session-binding is properly configured.
3. Be sure to uninstall all old JRE versions and install the latest (8u221).
4. Verify that JRE 9 or newer is not included on the client machine.
5. If the application used custom Java Beans, consider recompiling, repackaging, and resigning the JAR(s).
6. Disable legacy_lifecycle (in Web Configuration). It is disabled by default, but it may have been enabled by the administrator.
7. Verify that the userid parameter is not being included in the URL.
Any one or more of the above could cause the error you mentioned. This does not mean other root causes are not possible, but the above are the most common.
> ... jump to the last record of the query (approx. 50000 records).
I don't know what the cause of the error is, but I'm curious to know which values have the following properties:
- Query Array Size
- Number of Records Buffered
Thanks to all. We will check the recommendations.
Just to add some information:
In the Forms trace the last entry was:
1433781 [ABORT_FORMS_DIED] Timestamp=140340, Msg=Forms encountered unexpected signal 15
We have done another test by creating a second instance of HTTP server but without a webgate and Oracle Access Manager. The same error happens after a while.
We could conclude that the error happens when the traffic goes through HTTP server instead directly to WLS_FORMS.
It looks like the parameter WLIOTimeoutSecs solved our issue after increasing the value in mod_wl_ohs.conf.
Juergen Menge, would you please explain what you mean by "WLIOTimeoutSecs solved our issue"? The default value for WLIOTimeoutSecs is 300 (5 minutes). Unless someone altered the default value, I see no way that this value would ever be reached in a properly configured environment. Was the default value changes and caused the problem?
We have modified two values in mod_wl_ohs.conf:
- WLIOTimeoutSecs 600
- Idempotent OFF
Now the Forms session isn't interrupted anymore when a long running query is executed.
The value was not modified before and the Forms session died after several minutes.
In ohs log we found the following entry:
[2019-08-20T08:28:45.0726+02:00] [OHS] [ERROR:32] [OH99999] [weblogic] [client_id: XXXXXX] [host_id: XXXXXXX] [host_addr: XXXXXXX] [pid: 115035] [tid: 139944144115456] [user: oracle] [ecid: 005^8QANPUL6iKxaw9aeMG000S5K000062] [rid: 0] [VirtualHost: main] <005^8QANPUL6iKxaw9aeMG000S5K000062> *******Exception type [READ_TIMEOUT] (no read after 120 seconds) raised at line 284 of Reader.cpp.
Thank you for the update. I will discuss this with Support and consider having them author a Support Note explaining this condition so others in the future can benefit from your effort.
That said, from a design point of view (and a user point of view) I don't know if I like the idea of a 5+ minute long query being executed in locking mode. As a user, I don't think I'd be willing to wait in a stuck state for that long. Seems like this could be designed differently. If the query is simply returning lots of data that will not be edited, why not consider sending the request to Reports or BI-Pub and release control of the form back to the user?? Just an opinion... Without knowing the real application, obviously all I can offer is an opinion
I found an old pitts entry for this. Maybe you check the related support ID there ..