We have the following configurations:
WebLogic 10.3.3
JAVA 1.6
Ulimit set to 65K -> maximum allowed by the OS
OS - Solaris 32 bit.
We need to support SHA2 certificate in keystore and we had to enable JSSE=true in Weblogic to do that.
Problem: Nodemanager, Admin and managed server come up correctly but after 40 mins, JVMS have too many CLOSE_WAIT to the Admin server. Then they stop taking requests after couple of hours with growing CLOSE_WAITs.
We applied 3 recommended patches from Oracle docs. Did not help.
Patch1, 2 -> to help JSSE=true to be read
Patch2- 10.3.3 defect with too many open files
can someone please share any more information?
Gave up trying options with WL 10.3.3 and upgraded the entire domain to WebLogic 12.1.3 and JAVA 1.8. Everything works just fine now.
Related
When my colleague attempts to connect he is having no issues. We both have previously been granted access to the server, and have established this is not an issue as my colleague can access the server on my Desktop though I cannot access the server on his desktop. (We both could up until recently when we had had to renew the server connection passwords).
We are both operating off 64-bit, Windows 10 desktops with the same Java version and are both using Oracle SQL Developer 19.2.1.247.
When I go to about properties and compare both in excel we see no differences.
We're quite confused why this is happening.
I am trying to connect to a remote sonarqube 6.2 server from Sonarlint 3.2 plugin in eclipse neon. I am able to connect to my local server http://localhost:9000.
But When I am trying to hit the remote sonar server I am getting below error:
Fail to request https://xxxxxxxxxxxxxx:xxxx/xxx/api/system/status
Please advise.
I ran into this problem myself using SonarLint 3.1 and SonarQube 6.7.
In IntelliJ I kept running into this error message
Failed to connect to the server. Please check the configuration.
Error: Fail to request https://<SONARQUBE>/api/system/status
However I could access that URL through my browser without any issues.
When you WireShark the requests coming from the browser and the IDE you can see that the cypher suite is quite different and that the IDE plugin gets a TLS handshake failure.
That lead me to discover that Java still ships with limited strength cryptographic functions. That’s either because of US export policy or because nobody has gotten around to fixing it. The internet isn’t quite sure.
Either way, you can download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Once I installed those onto the IntelliJ JVM, I no longer got the underlying TLS handshake failure when trying to connect to SonarQube and the connection works.
I'm using windows 7, eclipse neon.3, liberty server 17.0.0.1, WebSphere® Application Server Liberty Tools 2016.0.0.v20170505_1729
I have a probem when starting the liberty server from eclipse. The server is actually starting fine, but eclipse is just showing the 'Starting'- status and never get confirmation that the server is actually started. After the predefined timeout, eclipse is giving up and stops the server.
If I start the server from command line, everythings works fine and eclipse confirmed that the server is running. Have tried both ibm sdk 8 and oracle.
What is actually the WDT (or eclipse) using for determing the server is started or not ?
WDT is looking for this message from the server: CWWKF0011I: The server is ready to run a smarter planet.
Please check the following link to make sure you have not changed something in the server configuration that is causing the tools to miss the message:
https://www.ibm.com/support/knowledgecenter/en/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/r_limitations.html
I have an application that is running on a secure site and I installed the ehcache probe jar. Everything seems to be running but I can't access it through the browser because by default the server is running on secure https.
Is there a way to view the monitor through https://myserver.com:9889/monitor?
I'm using the 30-day trial development version of ehcache monitor. Could this be the problem and perhaps the paid production version works?
Thanks.
You are using a free version and some resources maybe are not working or has a restriction , remember all that is free won't work perfect.
I am new to tridion and trying to setup a new instance of tridion 2011. I was able to successfully publish all my requests to file system and broker db. Suddenly it stopped publishing and all requests are stuck in "Ready to transport" mode.
I have already gone through many related threads on this forum, but could not sort out the problem. I am using Widows server 2008, with Jre 1.6 (32 bit and 64 bit both installed). Any pointer to finding the issue will be appreciated.
First thing to check is if your transport service is running.
Second thing I would look at is the config files to make sure the transport service is looking in the same directory that the publisher is storing them. Then see if files are being dropped in the transactions folder on the CM machine.
In our environment this issue arose due to a change in the SSL ciphers supported on our Content Deployer server. We are using the SSHFTP transport protocol and for security reasons the RC-4 cipher suite that had been supported by the CD server was no longer supported. We logged a case with SDL support and they issued Hotfix CD_2011.1.2.2350 which adds support for the stronger ciphers.
Unfortunately, the logs gave absolutely no indication of the issue, even with TRACE level logging.
So if you face this issue and you're using SSHFTP and the other solutions don't work for you, maybe this will help.