Daniel Nashed’s Blog

RunFaster=1 for Domino on Linux

Daniel Nashed — Mon, 30 Apr 2012 10:39:06 +0200

We have been tracing this problem together with IBM for half a year and finally got a solution for a performance problem that blocked us from migrating 8500 users from Groupwise to Domino.
When we first started to run large scale imports to Domino (load with creating many documents with attachments in parallel with multiple workstations) I discovered a slow down for some transactions by 100 ms or even a multiple of 100 ms.
Part of the problem was based on issues introduced with a newer kernel that SuSE is using in SLES11. The new process scheduler CFS which I have blogged earlier needs some "tuning" to work nicely with Domino.
SLES 11 SP2 even ships with a 3.0 kernel which has an updated CFS implementation which needs a different tuning setting than SP1 (you need to set echo NO_FAIR_SLEEPERS > /sys/kernel/debug/sched_features after reboot).
In addition another disk I/O issue is fixed in the shipping 3.0 kernel which in addition reduces the I/O.

Still those settings did not help to completely solve the problem and we continued tracing. I have build test tools to do all sort of load tests locally and remotely to figure out what could cause the delay.
And it turned out that there was an issue with the IOCP handling (sys-epoll) which caused delays in the thread pool coordination.

Last week we got a hotfix (853FP1HF85) containing a changed behaviour in the way the worker threads are coordinated (SPR PHEY8RJHXR).
This SPR is already submitted for 8.5.4 and should hopefully make it into 8.5.3 FP2.

In testing the response time for a normal work-load was five times lower than without the fix!
In my testing with an attachment workload I had even better results.

Load Test Environment

- 30 threads
- 100 documents
- attachment size 2 MB
- create 8.5.3 mailfiles from template
- search for all documents after writing them

nshload -t30 -w100 -a /largefile.txt -s servername

Infrastructure

- SLES 11 SP2 64bit Domino 8.5.3 FP1
- fast quad-core CPU, fast, local RAID10 disks, 32 GB RAM
- Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

Special Configuration
- amgr disabled
- transaction logging enabled
- NO_FAIR_SLEEPERS for most tests beside one test
- noop scheduler instead of CFQ for disk devices

I have tested with out network interface creating the documents locally as a reference.
Than I tested without the fix but NO_FAIR_SLEEPERS set
After that I did a test with the hotfix.

And I have got the following results

	no network	without fix	fix + fair sleeper	fix + no fair sleeper
elapsed time (sec)	56	828	78	68
response time client (ms)	2	40-60	5	3

Response time improvment: 12 times faster (reduced to 8%)
Elapsed time improvement: 16 times faster (reduced to 6%)

We have a dramatical performance improvement with the hotfix.
You can also see that the NO_FAIR_SLEEPERS is helpful but the real performance boost we get is because of the hotfix :-)

Our current nightly migration runs for 24 hours. With this fix I would assume that at least it would be done in 1/5 of the time (really careful estimation if the migration tool does not cause other delays) .
So we would be done in 5 hours instead of 24 hours.
This solves our performance issues during migration and also improves response time during normal operations dramatically.

I have also done another tests creating documents with attachments in parallel with 100 threads.
There was no response time slow down with the nshopen tests. I got the same 3 ms average response time.
The test creating 100 documents with 100 threads and a 1,5 MB attachment in parallel took 187 seconds!!!

If you are not running into critical performance issues you should wait for the next fixpack to ship.
In case you are having issues you should first looking into the other performance optimizations I have posted (CFS changed, switching from CFQ to noop disk I/O scheduler).
If that does not help you could open a PMR to get the hotfix :-)

I am looking forward to the Domino performance team to ship new performance benchmark comparing Linux with Windows in future :-)

-- Daniel

Linux I/O Performance Tweek

Daniel Nashed — Mon, 23 Apr 2012 06:51:09 +0200

During a performance troubleshooting session at a customer we found a very interesting tuning option that can boost your storage performance dramatically.
This setting is really helpful for SAN environments, SSD discs, virtual servers and also physical servers using RAID storage.

Current Linux versions do use the an I/O scheduler called CFQ (complete fair queuing).
This scheduler is helpful when you have simple local disk where Linux can optimize the I/O requests by re-ordering them.

But this can introduce latency with modern I/O devices.
If you have a caching RAID controller or a SAN, SSD disk the hardware backend is far more effective optimizing the I/O.
Most disk sub-systems also include a larger amount of cache to optimize the I/O.

Changing the I/O scheduler from "CFQ" to "noop" can dramatically reduce I/O latency.
The "await" in the iostat output shows the time needed for an I/O request from the application to the queue, to the disk and back to the application.
Even if the service time of the device is good (svctm) the await could be a lot higher because of CFQ that tries to re-order the I/O requests.

If you switch from "CFQ" to "noop" all I/O requests are send to the I/O device directly without any additional delay.
You will notice that the await is dramatically reduced.

We have seen good results with SAN environments and also physical disks.

Here is an example for two tests that we did with a larger physical machine with RAID 10 disks.

First Test

I have used 80 thread to read 32000 docs each (80 separate local databases on the server with small documents)

The result was as follows:
51 sec with CFQ scheduler
28 sec with noop scheduler
19 sec all data in cache.

Second Test

80 threads creating 2000 docs each
with noop 42 sec
with cfq 132 sec

You can see from the results that we have dramatic difference in performance between CFQ and noop.
The server had a lot of RAM and repeating the test did not show and read I/O.
So all data has been served from cache in this case! That means the 19 seconds is without physical disk I/O. Just the processing time in back-end.

Side note for File-System Cache

Even for larger environment caching can effect the results. So for all tests beside the last test we have flushed the file-system cache.

Here is the cache flush command on Linux
echo 3 > /proc/sys/vm/drop_caches

So if you do your own testing you should

Here is a short extract from an older IBM Linux redbook that is a great summary of the background:

Select the right I/O elevator in kernel 2.6
For most server workloads, the complete fair queuing (CFQ) elevator is an adequate choice
as it is optimized for the multiuser, multiprocess environment a typical server operates in.
However, certain environments can benefit from a different I/O elevator.

Intelligent disk subsystems
Benchmarks have shown that the NOOP elevator is an interesting alternative in high-end
server environments. When using IBM ServeRAID or TotalStorage DS class disk
subsystems, the lack of ordering capability of the NOOP elevator becomes its strength.
Intelligent disk subsystems such as IBM ServeRAID and TotalStorage DS class disk
subsystems feature their own I/O ordering capabilities. Enterprise class disk subsystems
may contain multiple SCSI or FibreChannel disks that each have individual disk heads and
data striped across the disks. It would be very difficult for an operating system to anticipate
the I/O characteristics of such complex subsystems correctly, so you might often observe
at least equal performance at less overhead when using the NOOP I/O elevator.

Virtual machines
Virtual machines, regardless of whether in VMware or VM for zSeries®, may only
communicate through the virtualization layer with the underlying hardware. Hence a virtual
machine is not aware of the fact if the assigned disk device consists of a single SCSI
device or an array of FibreChannel disks on a TotalStorage DS8000. The virtualization
layer takes care of necessary I/O reordering and the communication with the physical
block devices. Therefore, we recommend using the NOOP elevator for virtual machines to
ensure minimal processor overhead.

How do you change the settings?

You can change the setting dynamically for testing with this manual command (example for hda device)

#
echo noop > /sys/block/hda/queue/scheduler

If you want to permanently change the scheduler for all block devices you can set it as a boot option.

Edit /boot/grub/grub.conf and enter in kernel line elevator=noop.

Conclusion

You should really look into this setting and try it in your environment.
Changing the settings dynamically in an production environment does not cause any issues and you can see with "iostat -x 1" how the "await" will change.

I am interested in your feedback from your environments.

-- Daniel

Process iCalendar attachment while in other mailfiles

Daniel Nashed — Thu, 19 Apr 2012 14:17:31 +0200

Normally you can only import iCal data into your own mail-file. This limitation sounds like working as designed.
But there is a notes.ini setting that I just found that allows import into other mail-files as well :-)
Also other databases with calendars should work according to the TN.

Just found it in a technote (#1469271) checking for something else ...

notes.ini ICAL_IMPORT_MANAGED_USER=1

-- Daniel

New Traveler Companion APP 2.0.7

Daniel Nashed — Wed, 18 Apr 2012 16:46:54 +0200

Description of the update just says "Bug Fixes"

Hmm.. still a good idea to install ..

-- Daniel

ComputeWithForm Performance

Daniel Nashed — Mon, 16 Apr 2012 10:43:28 +0200

I have done some analysis for a customer which lead to a PMR and a SPR which is marked as an enhancement request.
We got feedback that this is not going to be addressed in the current code stream but I think this is still a quite relevant improvement specially for customer and business partner applications.

In our analysis it turned out that with NSFNoteComputeWithForm (and also when you use the derived functions in LS and Java)

a.) subforms and shared fields are not cached from cache.ndk

b.) and also when searching subforms and shared fields (potential more we did only find those in client_clock data) the design collection is searched instead of using FINDDESIGN transactions.

So not only the cache.ndk is not used but also those transactions are not optimized.
It means that if you have multiple subforms and shared fields for each of them the design collection is read -- every time.

For a database with many design elements this means a quite lot overhead.
So instead of zero bytes going over the wire if cache.ndk would be leveraged (after the design element has been loaded for the first time) instead of a cheap transaction
(FINDDESIGN -- transfering only a couple of bytes) we have many transactions reading the design collection.
For a database with large design each of those lookups could be multiple 64k read transactions until the design element is found.

Those transactions look usually like this:

(442-79 [618]) READ_ENTRIES(REPC125757C:00308E76-NTFFFF0020): 34 ms. [76+64958=65034]

The internal number for the design collection is 0xFFFF0020. And you can see that a 64K block is read.
The number of reads depend on the size of the database design and where in the design collection the design element is located.
So you could end up having 3-15 additional transactions with

This sounds like code that has not been changed when the design cache was introduced long time ago.
We got a SPR # BHUY8SELK9 which marked as enhancement request and is not planned to be addressed in this code-stream.
If you are interested to have this enhanced you could open a PMR referencing this SPR.

For now you should be very carefully with subforms and shared fields -- and big main forms if you use "ComputeWithForm" in an application that you access on a server over WAN connections.

-- Daniel

Unix/Linux Start Script Update for high CPU issue

Daniel Nashed — Tue, 10 Apr 2012 12:19:09 +0200

There was an issue that in some cases when the monitor command was running and the shell was closed, the script could not catch the dead text file caused by the shell.
I have changed the trap events and now I hopefully trap all signals that could occur.
We got this problem only on some platforms. And I cannot test on all different versions of Linux.
I hope this change resolves all cases. If not send me your feedback.

You can request the new version on the start script homepage.

http://www.nashcom.de/nshweb/pages/startscript.htm

-- Daniel

V2.4 10.04.2012

Problems Solved
---------------
Solved an issue when closing a terminal window while the monitor was running.
With some OS releases and some shells this caused that the script did not terminate due to issues in the shell.
This could lead to high CPU usage (100% for one core) for the script because the loop did not terminate.
The change to catch more events from the shell should resolve this issue.
If you still run into problems in this area, please send feedback.

FTIndex Crash with C-API based tools caused by a change in D8.5.3

Daniel Nashed — Tue, 10 Apr 2012 08:43:21 +0200

We ran into this problem quite badly and the root cause was hard to track.
One of my applications (nshrun -- a tool to do multiple tasks in parallel on multiple databases) started to crash without a meaningful call-stack.
I started to figure out the root cause and identified that the C-API call FTIndex causes a crash of the calling function because the stack is damaged.

It turned out that IBM changed the structure of the statistic buffer for FTIndex by adding two new variables.
This change caused incompatibility with all existing applications using this structure with FTIndex.
When using a previous version of the C-API toolkit the memory buffer passed to the function was to small and the function did overwrite memory which caused the stack to be corrupt.

The problem exists with 8.5.3 and 8.5.3 FP1 and will be corrected in 8.5.3 FP2 and 8.5.4. The exposed structure will be reverted back to the old format.
In the meantime to get your application working you have multiple options

a.) wait for 8.5.3 FP2 or 8.5.4
b.) don't use the statistics returned and pass NULL as the parameter
c.) recompile just for 8.5.3 with the current 8.5.3 C-API
d.) redefine the structure in your earlier toolkit version and compile -- for older versions the bigger buffer does not cause any issues

There is a upcoming technote (TN #1590244) which is not yet released and the SPR we got for the problem is APAR#LO68258/SPR #VDES8SMFCJ.

I am going to compile my applications with a changed header structure to ensure it will continue to work with all releases of Domino.

-- Daniel

STATUS LNPUBLIC FTIndex(DBHANDLE hDB,WORD Options,char far *StopFile, FT_INDEX_STATS far *retStats);

In version 853, the structure FT_INDEX_STATS was updated as shown below in both product code and the C API toolkit.
typedef struct
{
DWORD DocsAdded; /* # of new documents */
DWORD DocsUpdated; /* # of revised documents */
DWORD DocsDeleted; /* # of deleted documents */
DWORD BytesIndexed; /* # of bytes indexed */
DWORD Merges; /* # of index merges */
DWORD MergeMsec; /* Msec spent merging */
}
FT_INDEX_STATS;

In previous versions on the product, this structure was defined as shown below.
typedef struct
{
DWORD DocsAdded; /* # of new documents */
DWORD DocsUpdated; /* # of revised documents */
DWORD DocsDeleted; /* # of deleted documents */
DWORD BytesIndexed; /* # of bytes indexed */
}
FT_INDEX_STATS;

Domino on Linux Plattform stats might use 100% CPU

Daniel Nashed — Thu, 22 Mar 2012 20:52:47 +0200

We ran into this issue on a couple of customer sites. It is not completely sure in which release starts (in a fixpack of 8.5.2 and in 8.5.3 for sure).
The problem is that the server thread responsible for platform stats might use 100% of one CPU thread.
Basically there is an issue when reading a system file in a loop.

There are two SPRs involved in this

SPR #YPHG8ET496 will be fixed in 8.5.3 FP1
SPR #PHEY8KRJJ7 will be fixed in 8.5.2 FP2 and 8.5.4

If you run into this problem in your environment the only work-around is to disable the platform stats via PLATFORM_STATISTICS_DISABLED=1.

What also happens in this case is that the server might not terminate cleanly because the platform stat server thread is in a infinite loop which does not terminate.

-- Daniel

Companion App 2.0.6 released -- fixes session based authentication issues

Daniel Nashed — Tue, 20 Mar 2012 09:28:27 +0200

A new update for the companion 2.0.6 app has been releases which fixes the session based authentication issue we discussed.
According to the description this is the only fix in the app. Again you should still use basic authenticaton also to ensure that the device detects password changes.
But it is still good that IBM fixed this issue :-) Huge thanks for the very fast response!

-- Daniel

New Traveler Db Usage command in 8.5.3.2

Daniel Nashed — Fri, 9 Mar 2012 10:41:39 +0200

There is a new tell command to show how much data is synced to devices.
This command is interesting to figure out how much data users are syncing.

The tell traveler dbusage command is new in 8.5.3.2 and the results look like the example below.

With iOS devices you cannot prevent via policies that users sync all their mail.
But there is a general switch for the whole Traveler server in NTSConfig.xml to reduce the maximum limit that the server will sync -- independent from the user settings

Sets maximum mail filter window.

Sets maximum calendar filter window.

Sets maximum journal filter window.

-- Example Output from dbusage command (my server has just two users) --

tell traveler dbusage
Lotus Traveler Database Statistics
Accounts : 2
Devices : 5
Device documents: 8814
Domino documents: 3492
Highest Total Usage Documents Percentage
-----------------------------------------------------------------------
Daniel Nashed/NashCom/C=DE 2904 83,16
mobile/NashCom-Net 588 16,84
Mail documents: 2131
Highest Mail usage Documents Percentage EMail filter
-----------------------------------------------------------------------
Daniel Nashed/NashCom/C=DE 2120 99,48 30 days
mobile/NashCom-Net 11 0,52 5 days
Calendar documents: 63
Highest Calendar usage Documents Percentage Event filter
-----------------------------------------------------------------------
Daniel Nashed/NashCom/C=DE 61 96,83 30 days
mobile/NashCom-Net 2 3,17 14 days
Contacts documents: 1262
Highest Contacts usage Documents Percentage Contact filter
-----------------------------------------------------------------------
Daniel Nashed/NashCom/C=DE 699 55,39 unlimited
mobile/NashCom-Net 563 44,61 unlimited
To Do documents: 3
Highest To Do usage Documents Percentage Task filter
-----------------------------------------------------------------------
mobile/NashCom-Net 2 66,67 incomplete only
Daniel Nashed/NashCom/C=DE 1 33,33 incomplete only
Notebook documents: 0
Folder documents: 26
Highest Folder usage Documents Percentage Folder filter
-----------------------------------------------------------------------
Daniel Nashed/NashCom/C=DE 19 73,08 unlimited
mobile/NashCom-Net 7 26,92 unlimited
Command DbUsage complete.

Traveler 8.5.3.2 released -- Isuses with older companion app

Daniel Nashed — Thu, 1 Mar 2012 13:18:20 +0200

Traveler 8.5.3.2 ( aka FP2) has been released.

A couple of issues have been fixed in this FP. See details here http://www.lotus.com/ldd/dominowiki.nsf/dx/Lotus_Notes_Traveler_APAR_listing#8532

This fixpack is also needed to use the new companion app version 2.0.5.
A couple of customer updated their companion app to 2.0.5 could not read encrypted email any more.
The new Traveler version did solve this problem. IBM is still investigating.

Also there is some new functionality in the new companion app in combination with the new Traveler release.
You can now control if the user can export the message and if the companion app only works with trusted certs.

See details here -> http://www.lotus.com/ldd/dominowiki.nsf/dx/Lotus_Notes_Traveler_Companion_security_settings_LNT853

Probably when introducing this new functionality some compatibility issue with earlier releases has been introduced.
The documentation says that if you use this new functionality you need to update your companion app.
But it looks like something went wrong in this area.

Updating the companion app to 2.0.5 should solve the issue.

I had also some issues with intermittent sync problems after the update but that might be related to my installation -- still testing.

--- Update 06.02.2012 ---

my sync issues are solved. it turned out that my Android device needed a full sync and that the full sync blocked sync for my iPhone and iPad with the same user.
this works as designed and if I would not have stopped the Android device syncing, the problem would have gone away earlier.

the second update is that it turned out that the customers reporting companion app problems had turned on session based authentication.
smartphones and the companion app cannot handle forms based authentication properly and need basic authorization headers!
you have to setup basic authenication for all Traveler servers that do not use secure reverse proxy.
in the case of a reverse proxy the proxy handles the authentication and uses basic authentication.
that authentication is forwarded to the Traveler server and depending on the proxy it makes sense to use multi server authentication to reduce the overhead for the session.

when switching to basic authentication the companion app worked again.

-- Daniel

Here is the documentation page for the update.

http://www.lotus.com/ldd/dominowiki.nsf/dx/Lotus_Notes_Traveler_8.5.3.2

SSL Issues on Client and Server

Daniel Nashed — Tue, 28 Feb 2012 22:11:35 +0200

There is an issue with the way the SSL key buffer is managed that will fixed in 8.5.4.
The problem can occur with concurrent (multi-threaded) access to the SSL ring buffer (used to store SSL sessions).
By default the size of the buffer is quite small and in some cases the size of those entries need to be increased on the fly by reallocating the entry.

This is mainly an issue on Servers but I ran into this issue on my Notes Client with HTML mail loading remote images from websites using SSL.

I had crashes for some mails and I only figured out what was going wrong when debugging the logs.
It turned out that some SSL sites need larger buffers and due to the multi-threading and the reallocation caused the crash.

In 8.5.3 there is a new parameter for server and clients to use a new implementation of this code. It will be default in 8.5.4 but you can enabled it in 8.5.3

SSL_USE_ADDSESSION2=1 will enable the new code.

You should set this parameter for all servers and clients that use SSL to avoid crashes.

And you could increase the buffer size of each ring entry via for example SSL_SESSION_SIZE=4096 to avoid reallocations.

Reference: SPR # SFPN69ET56 / http://www.lotus.com/ldd/r5fixlist.nsf/Public/E9BAC1A4277A6FD88525709200001E26?OpenDocument

-- Daniel

Domino on Linux Performance Tweaks with current Kernels

Daniel Nashed — Mon, 27 Feb 2012 09:20:40 +0200

We found a performance issue with SLES 11 and also RHEL 6. Due to a new process scheduler (CFS) introduced there seem to be timing issues with some new functionality.

The new scheduler CFS is the Completely Fair Scheduler which has some new functionality.
From what we figured out so far some functionality of CFS causes timing issues with the Domino server.
The Domino server has many active threads and processes which seem to not work well with the standard settings of CFS.

What happens is that under some load the response time of the server increases. There are some transactions that take 100 ms longer than usual.
Domino Development are still working with the Novell on identifying the root cause. We have an escalated PMR open with IBM and and a case open Novell and they are still trying to figure out what in detail is going wrong.

This recommended workaround has no negative affect on the system that we have seen, nor do we expect a negative affect.

The work-around we found is to disable some functionality in CFS.

As root, run the command

echo "0" > /proc/sys/kernel/sched_features

This will set the CFS features to 0 until the system is rebooted. If the system is rebooted you will need to run the command again.

I have small test application "nshopen" that opens many documents and reports the response time.
Let me know if you want this test application for performance testing your Linux machines with and without the fix.

We are still trying to find out what exactly is going wrong with the timing and there is some other ongoing work.
I will post an update when we find more details. For now you should use the mentioned tuning.

-- Daniel

Cluster Failover Improvement since 8.5.2

Daniel Nashed — Tue, 21 Feb 2012 12:46:25 +0200

I thought I blogged about it long time ago already but sounds like I forgot.
There used to be a parameter in earlier 8.x releases that does some kind of failover.
Beginning with 8.5.2 there is a new parameter that can be set thru the desktop policy settings.
This parameter does avoid almost all prompts when a server goes down and switches to a different server.
Also when the home server is up again it will fail back :-)
That's part of the failover improvements in 8.5.2.

But you still need to enable this setting to have the failover happen without any kind of prompts.

Note: The old parameter is HidePromptFailoverInc=1 you should remove this parameter and replace it with the desktop setting or the FailoverSilent=1 setting!

Info from the technote:

#2 - Enable "FailoverSilent" notes.ini variable
In certain circumstances the Notes client will prompt to inform the user that the current server is no longer available and that it will fail over to a new one. These messages may cause uncertainty for the end user. Enable via policy the "FailoverSilent" notes.ini variable, which will minimize any failover-related messages or dialogs being displayed to users. By applying the "Enable silent failover when a server goes down" Desktop Policy setting (Desktop Settings -> Mail- > Client Settings), users will rarely encounter any prompts.

Lotusphere Comes to Düsseldorf

Daniel Nashed — Fri, 3 Feb 2012 11:10:53 +0200

Final Call for this year's Timetoact Group's LCTY Thursday 9. Feb in Düsseldorf .
Last year the keynote presentation was even better and more to the point than the OGS in Orlando.
It will be a great summary with the highlights from Lotusphere again.

I am looking forward meeting many of you in Düsseldorf.

-- Daniel

Find details here

http://www.timetoact.de/ttacms.nsf/id/lotusphere-comes-to-you-lcty-nachlese-2012-rheinland

Traveler HTTPS Only

Daniel Nashed — Mon, 23 Jan 2012 09:40:22 +0200

We ran into issues with double password dialog when accessing the Traveler homepage (servlet) in a pure HTTPS environment with only authenticated users. So this is mainly a issue with disabled anonymous access.
The server has HTTP disabled and only HTTPS running for security reasons.
Because basic authentication is required in order for mobile devices to detect wrong passwords (they cannot read the forms based login return code used by SSO configurations) no HTTPs cookie is present.

By default the realm used by the server is set to the servlet and the image on the Traveler homepage comes from the /traveler/images directory.
That's why sometimes devices prompt for another authentication.

To avoid this issue you can set a "WEB_REALM_STRING" "/" in TrueSyncServer section of NTSConfig.xml

Example:

This will set the realm to the root instead of a sub-directory.

In our configuration this solved the double authentication issue.

-- Daniel

Lotus Traveler email Antivirus

Daniel Nashed — Mon, 23 Jan 2012 08:29:01 +0200

The Mail-Routing Configuration for a Traveler Server uses the home-mail server of the user to send outgoing mail.
But in some customer scenarios the home-mail server does not run antivirus software to scan emails.

If you have separate gateway servers scanning your inbound and outbound mail traffic there is a new Traveler setting that can help.
You can configure servers used for outbound mail instead of using the mail-server.
This setting will send outbound mail directly to the configured servers.

The settings OUTBOX_MAIL_SERVERS in TrueSyncServer section of NTSConfig.xml. It is a comma delimited list of servers.

Example Configuration:

NTSConfig.xml

All mail will be routed thru those servers.

There is still one gap for sent messages. The messages will be saved to the end-user mailfile without any way of active anti-virus scan.
Currently you can only periodically scan all mail databases for viruses.

There is no current plan for integrating Anti-virus support for Lotus Traveler.
But development is thinking about a new option to save "sent" messages without the attachment.
This way no anti-virus scanning is needed for "sent" messages.

In most of the cases there are no attachments being send from a mobile device. So I don't see it as a high risk right now. But it is still a gap.

From my point of view this new setting and the planned new option to not save the attachment in "sent" messages does fit most customer environments.
What do you think?

-- Daniel

IBM Lotus Symphony Viewer

Daniel Nashed — Mon, 9 Jan 2012 06:49:54 +0200

In case you missed it... IBM released a Symphony Viewer that allows to view ODF files on your iOS device.
It's a first version but you see from the growing list below that IBM is taking their mobile strategy quite serious.

-- Daniel

Important Lotus Traveler Fixpack 8.5.3.1 Released

Daniel Nashed — Wed, 16 Nov 2011 16:34:19 +0200

This fixpack should solve the iOS issues I mentioned in my previous post.
You should update your Traveler Server ASAP.

Here is a link to the Fixcentral Download

http://www.ibm.com/support/fixcentral/swg/selectFixes?parent=ibm~Lotus&product=ibm/Lotus/Lotus+Notes+Traveler&release=All&platform=All&function=all

And here is a list to the complete fixlist

http://www.lotus.com/ldd/dominowiki.nsf/dx/Lotus_Notes_Traveler_APAR_listing#8531

The issue for activities has been fixed and the two new iOS5 features are supported.

• Support Folder Management Features on Apple iOS 5 and Later Devices
• Support for Follow Up Flags on Apple Devices

A big THANK YOU to the Traveler team for this quick fix and also adding those new features.

-- Daniel

Traveler Performance Issue iOS 5

Daniel Nashed — Thu, 10 Nov 2011 09:14:10 +0200

Traveler with the latest fixpacks installed supports iOS5. Only the new functionality introduced with iOS5 are currently not supported and does not work yet.
After the first larger customers migrated it turned out that this new functionality causes performance (high CPU on Traveler server, shorter battery life for the Apple device) issues with Traveler when enabled.

IBM is working on a fix for this issue and we can expect a fix delivered soon.

In the meantime you should avoid the following new functionality:

1. Mail flagged (known as Domino Follow up).
2. Creating, renaming, moving and deleting folders on the Apple device.
3. Reminders (known as Domino To Do).

IBM will update the TN https://www.ibm.com/support/docview.wss?uid=swg21512456 with information about the fix once it has been released.

-- Daniel