rblog only

Smooth and easy as always, now running 4.1.7, mainly a security patch.

I started to get preeettyyy annoyed by the bad performance of my blog. Did some research and decided just give the two lines a try in the .htaccess file

Code:

And, damn! It seems to work immediately and provide a major performance improvement. Why have I not done this before?

@Update:

Also added

Code:

Just now I still have some performance issues, but I suspect that to be caused by the database server struggling, not the web server.

I was not aware of this tool, the SnippingTool. After spending years using MsPaint when taking screenshots, I have now turned advanced.

While reviewing a SystemOut.log-file created by WebSphere I needed to remove all lines containing "SystemOut". Luckily I have installed Cygwin, so Perl to the rescue. Found this Q&A at StackOverflow.

Ended up with

perl -ni.bak -e 'print unless m!^.*SystemOut.*!' SystemOut.log

Original file > 80.000 lines, resultfile 195 lines...a bit easier to read...

Running on Windows7 I had problems with TortoiseSVN, I was unable to rename, move and such. Solution for this is to run Windows Explorer as administrator.

Initially I could also have checked out my working folder in the home directory of my own user, that should also solve the problem without the need to "Run As Administrator"

At IBM Hursley attending a workshop and having one-to-one meetings with WebSphere gurus together with Dino. Here just outside IBM Hursley.

At the Innovation Center, innovative clock...

Leaving IBM for the day. This picture is taken just at the roundabout outside of the area, we are really out in the backcountry

A bit further down, sheeps. Compared to IBM Hursley the main office of IBM in Norway is downtown.

Close to the end of the day, testing the Stonehenge Old Smokey, good one!

Just had an issue when trying to commit changes to SVN. Now using Collabnet Subversion Edge 3.2.2-3395.103. Have configured authentication using LDAP, that is Active Directory. Error message when trying to commit changes

Code:

Found this very strange since it was working without problems yesterday. Tried to restart both services several times, no help. Nothing found in the logs either.

Then trying to log on to the Edge admin console with my AD-user...not possible. Using the superuser, logged in, changed LDAP from using port 389 to 3268 as the console provides a hint to do: Hint: try 3268 for Active Directory servers . Restarted Apache and voila, up an running again.

My conclusion: AD ...arrghh!

Trying to configure Collabnet to authenticate using LDAP following the guideline at http://blogs.collab.net/subversion/subversion_ldap.

Got the error:

Code:

Fixed by reading this blog post sleeplessmonkey./../joys-of-apache-webserver-and-modules

Switch AuthLDAPAuthoritative to AuthzLDAPAuthoritative, problem solved.

After having successfully installed Workplace XT v 1.1.5.0 applying FP1 of Workplace XT, version 1.1.5.1 fails. The error message showing in the Install Shield is plain and simple, that is meaningless: null. In the log file I found "JVM_HOME = null".

Reported this as a PMR which helped me solve the problem. Simply just uninstalled v 1.1.5, then installed 1.1.5.1 since it is a cumulative fix. Info from IBM:

The Workplace XT 1.1.5.1-WPXT-FP001 fix pack installs a new, complete Workplace XT 1.1.5.1 system, or upgrades an existing Workplace XT system. Workplace XT fix packs are cumulative; each fix pack contains the base release and content from all previously released fix packs.

So seen, it would be possible just to scrap the existing installation including the registry path and install Workplace XT 1.1.5.1 directly.

Had an issue today after having installed the application engine and then the latest fixpack. WebSphere reported that the application started just fine, but when accessing http://my_server/Workplace it failed with a NullPointerException. Part of the stacktrace

Code:

This was in test, in the dev environment where it is working SystemOut.log reported

Code:

After a lot of cursing it turned out that the problem was caused by Windows and access to the share where the log4j-file was located. As a wild guess I granted access to "Everyone" and voila...it worked...Windows shares...simply hate it. WebSphere running as local system account, did not cause any problems in the dev environment, but test...don't know why yet.