Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

WebLogic has an excellent administration console that lets you monitor threads but that is limited to real-time monitoring. Unless you have additional software like OEM, you have to do a little extra work to get historical performance data out of WebLogic.

Recently I had a need to check on the usage of the WebLogic thread pool and given some of the constraints I've been working with, the easiest way to do that was to go look into the WebLogic managed server logs. These were found in $DOMAIN_HOME/servers/<managed_server>/logs.

The managed server log has INFO level log entries like this...
 Managed Server Log
####<Jun 27, 2019 9:16:22,429 PM AEST> <Info> <WorkManager> <host.domain> <managed_server> <Timer-2> <<WLS Kernel>> <> <uuid> <1561634182429> <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-002959> <Self-tuning thread pool contains 1 running threads, 3 idle threads, and 20 standby threads>


With a few commands this can be filtered down to something more usable like a CSV file...
 Command
ls -rt *.log* | xargs grep "Self-tuning thread pool contains" | awk -F"<" '{print $2 $15}' | awk '{print $18 "," $14 "," $11}' > thread_history.csv


This gives us output that looks like the sample below (note the output of thread pool statistics are in reverse order vs what is written into the log file). The CSV file columns are thread counts for "standby, running, idle".
 CSV File
...
14,0,2
4,11,1
9,6,1
4,11,1
...


Continue reading...  

, , ,

I've reviewed other Metal Earth Legends kits like Groot previously and I've grown to like this series so much I had to look at more kits in the lineup. Today I decided to do something different and build two kits - Starscream and Gollum. Of all transformers, Starscream has to be my favourite and Gollum...well he is just precious!
IMG_3966.jpg


Lets start with Starscream. This is a one and a half sheet model and fits in the medium difficulty scale for a Metal Earth kit. There is only one page worth of instructions, so it really doesn't take too long to build.
IMG_3950.jpg


The arms were built first. They're just mirror images of one another. After the arms, the front section of the torso was next. This section of the model was made mostly of a single part which was bent and folded like origami into the front section of Starscream.

IMG_3952.jpg IMG_3953.jpg


Continue reading...  

, ,

If you're a developer and work on a Mac, you've most likely hit this error at some point in time. The dreaded "Safari Can't Open the Page" error which tends to occur when self-signed certificates are used and changed on servers in a development environment.

Unfortunately all Safari tells you is "Safari can't open the page https://XXXX because Safari can't establish a secure connection to the server XXXX". As far as error messages go, it's not very useful. Also, there are no options to continue to the page anyway.
priv_1.png


The JavaScript Console doesn't provide any extra detail either, but it does mention SSL at least...
priv_2.png


There are two easy ways to get past this error however.

1. Use Safari's "Private Window" to open the page you want.

This approach is ok for a quick one-off event, but doesn't provide a long-term solution. This is because Safari will not keep settings for any actions performed within the private window.
priv_3.png


When opening the site you want to visit in a private window, you will be presented with a warning saying "This Connection Is Not Private". Click the "Show Details" button.
priv_5.png


You will be warned that the certificate is not valid, but you are also given a chance to visit this website anyway. Click that. You'll be prompted for your password and then Safari will open the website.
priv_4.png


Continue reading...  

, , , ,

I was emailed an interesting error recently at work that I've not seen previously. It was to do with the DBMS_PICKLER package being missing when using JDBC drivers from a WebLogic application. In this case we were upgrading from an earlier version of WebLogic to the latest (12.2) and that's where we started to see these errors.

This is what the stacktrace looked like...
 Exception
java.sql.SQLException: ORA-06550: line 1, column 17:
PLS-00302: component 'DBMS_PICKLER' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:494)
at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:446)
at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1054)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:623)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:252)
at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:612)
at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:223)
at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:56)
at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:907)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1119)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3780)
at oracle.jdbc.driver.T4CCallableStatement.executeInternal(T4CCallableStatement.java:1300)
at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3887)
at oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:4230)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1079)
at oracle.jdbc.oracore.OracleTypeADT.initMetadata12(OracleTypeADT.java:537)
at oracle.jdbc.oracore.OracleTypeADT.initMetadata(OracleTypeADT.java:477)
at oracle.jdbc.oracore.OracleTypeADT.init(OracleTypeADT.java:443)
at oracle.sql.ArrayDescriptor.initPickler(ArrayDescriptor.java:1499)
at oracle.sql.ArrayDescriptor.<init>(ArrayDescriptor.java:259)
at oracle.sql.ArrayDescriptor.createDescriptor(ArrayDescriptor.java:124)
at oracle.sql.ArrayDescriptor.createDescriptor(ArrayDescriptor.java:79)


That indicated that this had something to do with Array bindings, which I knew were used quite heavily in this case. However that wasn't the real issue. The earlier version of WebLogic we had didn't use JDBC drivers that made use of DBMS_PICKLER (11gR2 onwards), but WebLogic 12.2 has JDBC drivers that certainly do make use of it.

What the package does it no really relevant, it's an internal package that's to do with array and custom type binding. What is relevant is that it's owned by SYS. And JDBC appears to call the procedure as if it was in the SYS schema.

The trouble was...we had a table with the name 'SYS' that was inside the schema that the application was accessing. This table was created as part of some patching bug, but wasn't rolled back, so once we moved to new JDBC drivers, it all broke.

The solution was to rename that table to something other than SYS and everything went back to normal!

Continue reading...  

, , , ,