Month: <span>December 2011</span>

Initial connection to the Portal Server via an HTTP server reports: “Internal Server Error”.  Refreshing the browser results in a successful connection.

Enabling the plugin trace you can see the error

– TRACE: lib_rio: wait_on_socket: ServerIOTimeout fired.

In my case the IBM HTTP is on the same machine as Portal  and it’s not a cluster.  The default value for ServerIOTimeout is -1.

Ajusting to ServerIOTimeout=120 solve the problem

You can see in the TN 1411685 that this problem was found on System I but my server is on Linux.

From TN 1575247

Fortiguard contacted IBM to report a denial of service attack when a malicious packet is supplied to the Domino Server via Notes RPC.  This vulnerability is resolved in releases starting with 8.5.2 FP4 and 8.5.3

The following releases of IBM Lotus Domino Server are susceptible to this malicious attack:

• 8.5.2 FP3 and earlier
• 8.5.1
• 8.5
• 8.0.x

FG-VD-11-007  has been investigated by IBM and is tracked in SPR# KLYH8FTK5Y.  To address the issues, you are encouraged to apply the following IBM Lotus Domino Server releases:

• 8.5.3
• 8.5.2 Fix Pack 4 (or later Fix Packs)

One of my servers is runing for 305 days. I Know that 8.0.2 and Centos 5.2 are old but the strategy is if is not broken don’t fix it.

This server is for Sametime (chat only), SMTP and some mail users using Notes.

The webadmin message is from the server, and thanks to my datacenter too.

I don’t know if you can run a Windows box for a long time without reboots.

If you want to enable this feature go to this link

With the launch of Domino Upgrade Pack 1 Domino Designers need to know how to use REST and JSON.

I found a good tutorial about REST. It is a starting point.

This year i made several certifications and all goals achieved.

My certifications this year:

LOT-801  – IBM Lotus Domino 8.0 Application Development Update
LOT-851  – IBM Lotus Domino 8.5 Application Development Update
000-038           – IBM Tivoli Identity Manager V5.1 Fundamentals
LOT-910  – IBM WebSphere Portal 7.0 Deployment and Administration Update
000-377    – IBM WebSphere Application Server Network Deployment V7.0, Core Administration
LOT-913  – Developing WebSite Using IBM Lotus Web Content Management 7.0

The last certification was today LOT-913  with 100%. It was my first 100% on IBM Tests.

 the Traveler server is experiencing a high CPU situation for an extended time, here are some actions to take which should resolve this issue

From TN 1568658

An extended high CPU on a Traveler server can be caused by several issues.  

Here is an approach to resolve this issue:

1)  Make sure you have the latest Fix Packs for both Traveler and Domino installed as several known issues have been addressed in the Fix Packs.  

The latest Traveler Fix Pack can be found here.

The latest Domino Fix Pack can be found here.

2) Verify the number of HTTP threads based on the number of devices using the Traveler server.  The steps to check this are documented here.

3)  Run a Traveler database defragmentation which will clean up and reduce the database size.  This will run automatically after installing the latest Traveler fix pack.  If it has been over a month since the last defrag has been done, running this again will be helpful.   It is recommended to run a defrag monthly.

How to defrag the database is documented here.

4) If you have followed the 3 steps above, but the issue continues, you could be experiencing a known Domino Server issue related to the DelayQueue function.  This is documented in SPR RSSN8HPLKX / APAR LO63480.  

To identify this problem (on Traveler 8.5.2.4), issue the cmd: show stat traveler.delay*  

If the output displays the following 2 lines, then you have encountered this defect:

Traveler.DelayQueue.Count.WrongOrder.DiscDelQ =      
Traveler.DelayQueue.Count.WrongOrder.StateController =

The Domino fix for this issue is included in Domino 8.5.2.4 or later, which can be found using the link in step 1 above.
NOTE: This fix is already included in Domino Server 8.5.3 and higher releases.