Alexander the Great and IT

Reading about the Battle of Gaugamela, they say that at the base of the tremendous military success of Alexander was that
- his troops were highly skilled veterans,
- with a very short command chain;
- troops were also highly motivated and were very devoted to their general,
- the general would camp and fight with the troops
- the troops had vested interest in the war, in terms of boot, land concessions etc

Compare to IT world, which is more and more flooded with cheap unskilled overworked underpaid troops, and with almost more officers than troops (the Persian army), and you will see why most IT projects fail. Alexander would have fared better.



(this mosaic you can admire at the Napoli archeological museum, one of the most amazing museums on the Planet)

Unable to connect to the Oracle WSM Policy Manager

on a OSB domain with OWSM installed, we had this error when editing the policies associated to a WSDL-based service:

oracle.wsm.policymanager.PolicyManagerException: WSM-02120 : Unable to connect to the Oracle WSM Policy Manager due to the following error "javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3s://acme.com:8002: Destination unreachable; nested exception is:
javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain received from hqchnesoa102.nespresso.com - 10.53.5.192 was not trusted causing SSL handshake failure.; No available router to destination]". [Possible Cause : Destination unreachable; nested exception is:
javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain received from hqchnesoa102.nespresso.com - 10.53.5.192 was not trusted causing SSL handshake failure.; No available router to destination]

The root cause was that the Admin server was using a Demo Identity and trust store, while the Managed Servers were using a Custom one. Setting the Admin the same way as the Managed fixed the issue.

OSB Operations/Dashboard/Server Health

In PROD we have often stuck threads on the Admin whenever someone accesses the sbconsole at "Operations/Dashboard/Server Health" tab. The function apparently scans plenty of log files:

"[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE
          
               antlr.InputBuffer.LA(InputBuffer.java:86)
          
               antlr.CharScanner.LA(CharScanner.java:166)
          
               weblogic.diagnostics.archive.filestore.LogLexer.mLOGFIELD(LogLexer.java:141)
          
               weblogic.diagnostics.archive.filestore.LogLexer.nextToken(LogLexer.java:83)
          
               antlr.TokenBuffer.fill(TokenBuffer.java:69)
          
               antlr.TokenBuffer.LT(TokenBuffer.java:86)
          
               antlr.LLkParser.LT(LLkParser.java:56)
          
                    weblogic.diagnostics.archive.filestore.ServerLogFileParser.getNextServerLogEntry(ServerLogFileParser.java:109)
          
                    weblogic.diagnostics.archive.filestore.ServerLogRecordParser.parseRecord(ServerLogRecordParser.java:35)
          
                    weblogic.diagnostics.archive.filestore.RecordReader.getRecord(RecordReader.java:199)
          
                    weblogic.diagnostics.archive.filestore.FileRecordIterator.readRecords(FileRecordIterator.java:75)
          
                    weblogic.diagnostics.archive.filestore.FileRecordIterator.fill(FileRecordIterator.java:246)
          
               weblogic.diagnostics.archive.RecordIterator.fetchMore(RecordIterator.java:157)
          
               weblogic.diagnostics.archive.RecordIterator.hasNext(RecordIterator.java:130)
          
               weblogic.diagnostics.archive.DataArchive.countRecords(DataArchive.java:240)
          
                    weblogic.diagnostics.archive.DataArchive.getDataRecordCount(DataArchive.java:273)
          
                    weblogic.diagnostics.accessor.DataAccessRuntime.getDataRecordCount(DataAccessRuntime.java:380)
          
               sun.reflect.GeneratedMethodAccessor76689.invoke(Unknown Source)