Speeding Up JDeveloper 11gR1 on Windows

Scott S NelsonLeave a comment

Here’s a tip sent to me by Songpol Siengvisuth:

By default JDeveloper was installed with Oracle Look and Feel and while it looks nice, a customized Look and Feel like that actually consumes more memory hence worse performance. We can switch to use a simpler Look and Feel like Windows Default by following these Steps:

  1. In JDeveloper, Go to Tools > Preferences
  2. Select “Environment” and Look for “Look and Feel” dropdown, you will find “Oracle” is selected
  3. Change to “Windows” and Click OK
  4. Restart JDeveloper to active the new Look and Feel
JDeveloper Prefrences
JDeveloper Prefrences

After the restart you will find JDeveloper look much plainer but the improved performance is noticeable.

If you found this interesting, please share.

SSH NodeManager Headache Solved

Scott S Nelson1 Comment

[6/8/2016] I am going to leave the original post up to be honest about my own learning curve. Meanwhile, the better solution to this annoyance is to make an ssh call before starting the server in order to get the ~/.ssh/known_hosts file updated. That said, on to my previous misconception…

For the longest time I could not get the ssh NodeManager to work on my VirtualBox VM I use for proving out approaches. It was not a big problem to use the command line start, so I did, until recently I needed to precisely replicate the start up process used in production.

After much thumping of forehead on desk (and steering wheel, and pillow, and…) I found this nugget at http://www.pythian.com/blog/why-was-sshd-refusing-my-key/:

…In our environment, we are not using SELinux so we disabled it by setting SELINUX=disabled
in /etc/selinux/config and rebooted the system….

 

A sad alternative is to go through a bit of a console dance. After starting the admin server for the first time, keep an eye in the command/bash console for:

[user@host scripts]$ The authenticity of host 'host (127.0.0.1)' can't be established.
RSA key fingerprint is 78:a1:89:03:53:1c:5b:d2:8d:50:15:3f:84:b9:a2:6e.
Are you sure you want to continue connecting (yes/no)?

Once this appears, type ‘yes’ (sans quotes) in the console and hit enter. Then shut down the server from the WebLogic Server console. In the command/bash console, you will see and endless series of ‘y’s. Hit CTRL+C to stop the y parade, then start the admin server again. You may need to repeat this for the managed servers as well, but eventually it will start behaving.

I have seen some other solutions in various posts, but they are not complete enough to just jump in and follow. Once I have the time and motivation to try them out, I will update this post with my findings.

If you found this interesting, please share.

Customizing WebCenter Logging with WLST

Scott S NelsonLeave a comment

Like many enterprises, the one I’m currently working with only provides developers with the Monitor role in production. This requires scripting tasks that are well-documented for manually performing but take some real thinking and testing to get right as a script.

One of my team members frequently says that code should be self-documenting, so rather a long blog entry I thought I would simply post the script along with some minimal comments and see if everyone finds that useful:

def configureAdfLogHandlers():
#The full script has multiple methods, so I print the currently running method to follow along
	print 'Start configureAdfLogHandlers()'
	managedServers=cmo.getServers()
	for managedServer in managedServers:
		sname=managedServer.getName()
		path = '/Servers/' + sname
		cd(path) 
		lh = listLogHandlers(returnMap='true')
		for l in lh:
			lname = l.get('name')
#Even with this script, the odl logs are quite verbose and we run an automated arciving process. 
#To simplify the process, we just put the logs in the archive path since the odl log handlers don't provide an archive location option
			odlfile = '${domain.home}/logs/LOGS/${weblogic.Name}-' + lname + '.log'
			print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%'
			print '   Setting log handler configuration for ' + lname
			print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%'
#The custom code rarely uses any levels between debug and warning, and the notice level for Oracle code is too verbose for most trouble-shooting needs
			configureLogHandler(target=sname,name=lname,path=odlfile,rotationFrequency='daily',retentionPeriod='day',maxLogSize='1g',maxFileSize='100m',level='WARNING:7')
		print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%'
		print '   Setting logger configuration for ' + sname
		print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%'
#The custom code used by the application sets of warnings in these packages that are not issues for the application, so we set the level to ERROR here
		setLogLevel(logger='oracle.webcenter.page',level='ERROR:1',target=sname,persist='1',addLogger='1')
		setLogLevel(logger='oracle.webcenter.framework.service.Utility',level='ERROR:1',target=sname,persist='1',addLogger='1')
		setLogLevel(logger='org.apache.myfaces.trinidadinternal.skin.SkinCSSDocumentHandler',level='ERROR:1',target=sname,persist='1',addLogger='1')

connect(os.getenv('WLS_USER'),os.getenv('WLS_PW'),os.getenv('ADMIN_T3'))
configureAdfLogHandlers()
disconnect()
exit()

 

If you found this interesting, please share.

Speeding Up WebLogic Server Console First Access on Linux

Scott S NelsonLeave a comment

It has been posted many times, but since I ran across it again and it made a significant improvement, I’ll repeat it for others.

Add the following to your WLS start up arguements:

-Djava.security.egd=file:/dev/./urandom

If you are interested in details, see https://bugs.openjdk.java.net/browse/JDK-6202721

If you found this interesting, please share.

Fixing Silent Domain Builds with WebCenter Portal

Scott S Nelson2 Comments

Automating domain creation is important for enterprises to minimize maintenance cost and be prepared for efficient disaster recovery. One enterprise I worked with was struggling with the domains they were building through scripts as the Enterprise Manager was not working properly in the completed domains and the managed servers would come up in Admin mode.

After comparing the scripted domain to a manually created domain that worked correctly it was found that the paths for the libraries did not match. The paths in config.xml were missing the beginning of the path where the libraries were actually located. While the installation paths chosen were not the default paths, this did not entirely explain the issue, and internal processes made the custom paths highly desirable.

The correction for this issue was to add a function to the offline WLST script run on completion of the domain creation to correct the library paths:

def fixApplicationSourcePaths():
  appPathPrefix = os.getenv('DOMAIN_HOME')+'/applications/'
  cd('/AppDeployments/')
  deployed_apps = ls(returnMap='true')
  for app in deployed_apps:
    cd('/AppDeployments/'+app)
    apppath = get('SourcePath')
    if apppath.find('/app/')!=0:
      apppath = apppath.split('/')
      apppath = apppath[-1]
      set('SourcePath',appPathPrefix+apppath)
  cd('/Libraries/')
  deployed_libs = ls(returnMap='true')
  for lib in deployed_libs:
    cd('/Libraries/'+lib)
    apppath = get('SourcePath')
    if apppath.find('/app/')!=0:
      set('SourcePath',appPathPrefix+apppath)

With this change, domains were created consistently as desired.

If you found this interesting, please share.