12/16/2023 0 Comments Davmail socket timeout![]() Some task metadata is still present in the SOA repository, which needs to be removed.ĭelete the offending row from the wftaskmetadata table and restart the WebLogic managed server. This problem is related to an undeploy that had errors or failed somewhere (see MOS note 1597584.1). It is nice to see the pieces of the puzzle fit together. Here we see the workflow/getTask code again, which we actually also saw in the stuck thread information in Cloud Control. Second log entry Could not locate composite. One error would generate 3 entries in the logfile, but those three entries accounted for more than 1000 lines of stackdumps! So these errors were triggering the diagnostic watch, which in itself would fail, causing the application threads to get stuck.Īt .(WFTask.java:2528)Īt .(PersistencyService.java:941)Īt .(TaskQueryService.java:898)Īt (Unknown Source)Īt .(TaskMetadataService.java:1402)Īt .(WFTask.java:5874)Īt .(WFTask.java:4327)Īt .(WFTask.java:3662)Īt .(WFTask.java:2522)Ĭould not locate composite for workflow component myPartition/bpmcomposite!1.30/T05_CHECK.Įnsure composite has been successfully deployed, and that the SOA server has completed loading composites.Īt .(WorkflowServiceEngine.java:2806)Īt .(WorkflowServiceEngine.java:2421)Īt .(TaskMetadataCache.java:355)Īt .(TaskMetadataCache.java:619)Īt .(TaskMetadataCache.java:916)Īt .(TaskMetadataService.java:1339) The solution is to disable the diagnostic watches.Ĭd('/WLDFSystemResources/Module-FMWDFW/WLDFResource/Module-FMWDFW/WatchNotification/Module-FMWDFW')Īfter disabling the diagnostics watch, we started seeing stack traces filling up the server logfile of the SOA managed server. In a production environment, it is not recommended to have diagnostic watches configured as we have seen them to cause problems in the past. The following following piece from the note disturbed me a little: # > ĭigging through MyOracleSupport, I found MOS note 1417194.1 on WebLogic Diagnostics Module configuration, which can cause the problems relating to the MaxMessageSizeExceededException messages we were seeing. ![]() Apparently the AdminServer fails at communicating with the soa_server1 managed server. In the AdminServer logs the following relevant entries were found. But accessing the soainfra pages would fail. Enterprise Manager Fusion Middleware control homepage would show that everything is running fine. There were problems deploying ear files and accessing the BPM workspace etcetera. In one of our SOA/BPM environments, the stability of the WebLogic server running the SOA and BPM Suite was not as it should be.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |