Writings mostly about Lotus Notes/Domino...by me :
Jesper Kiaer,Espergærde, Denmark

Looking for a Notes/Domino developer? I'm available


RSS 2.0 Feed
Bookmark and Share
Goodbye NSF ...welcome XSF ...XPages Storage Facility
IBM Notes as development platform has been getting a good overhaul the recent years with the arrival of XPages.

This has really boosted, and blown new air into IBM Notes/Domino and opened up for a lot of new possibilities.

On the other hand the document database Notes Storage Facility ( NSF) has grown old (but maybe not ugly yet)
and there has really been no major evolution the last many years.

It is ridiculous the we have to deal with ancient old restrictions in 2014 like:

• It is slow or at least "not fast"
• Database has a maximum size of 64 GB
• Field size limits of (32/64KB)
• 64KB result limits on @DbLookup, @Dbcolumn etc.
• Can only create/edit 100 docs pr second otherwise it leads to "Time Creep" on the server




The most promising Document and Graph Database today is OrientDB.
In many ways it resembles IBM Notes, but it modern and has a lot of cool stuff like

• It is a Document and Graph Database
• Written in Java
• Master <-> Master replication like IBM Notes
• Virtually no limits
• You query with SQL
• Supports transactions
• and much more...

and it is FAST!

In 2013 I did a simple test in IBM Notes and OrientDB.
Create 10.000 documents, 2 text fields, one attachment of size 7KB.

In IBM Notes it took 191seconds, in OrientDB it took 19 seconds!!

So IBM ..at Connect 2014 I really hope you have seen the light and the need for a new document and graph database for IBM Notes/Domino, well for XPages only.
You can keep the NSF for the old stuff.

Please announce that 2014 will the year IBM Notes will release a new and modern Document and Graph Database for XPages.

Feel free to name it XPages Storage Facility or just XSF

Published by: Jesper B. Kiær at 23-01-2014 23:30:00 Full Post

Beware @MailDbName now returns a different result in version 9.0.1 of IBM Notes
Just a slight warning about @MailDbName in version 9.0.1 of IBM Notes.

I have a customer where they have a lot of old code which rely on @MailDbName and it has worked for years.
Last year they started to use Managed Replicas for mail databases, and @MailDbName would still return values as if the mail was server based.
In version 9.0.1 it has changed and @MailDbName now returns an empty string as if it is a local replica.

Published by: Jesper B. Kiær at 26-11-2013 11:15:47 Full Post

The extremely slow categorized views has been fixed in IBM Domino 9.0.1. Here is how to.
I have in former post on my blog, I have written about viewpanels in XPages in IBM Domino being very very slow.

Have a look at http://nevermind.dk/nevermind/blog.nsf/subject/viewpanel-performance-issue-confirmed-by-ibm.

Philippe Riand some time ago wrote to me that a fix would be available in 8.5.4 aka 9.0, but a apparently the fix did not make in time.
But in 9.0.1 there is a fix for the issue :-)

You can in the "What’s new for Developers in IBM Domino & Domino Designer 9.0.1" Webinar (must see) see how too use the new navigator way .
No wait ...I'll show you.

Go to xsp.properties and add the setting:

xsp.domino.view.navigator=ByNoteId

Done!



(the old way is xsp.domino.view.navigator=ByPosition)

I have just tested the old troublesome database.
The old way still very very slow, but changing to the new way of getting data by NoteId ....it now works and it is really fast ! :-)

Published by: Jesper B. Kiær at 11-11-2013 12:40:00 Full Post

Is Sametime just bloated and too complicated?
Stumbled upon this 970 page long Slideshow "IBM Sametime 9 Complete - Basic Features Installation - From Zero To Hero" from IBM on the Sametime 9.0,


http://www.slideshare.net/FrankAltenburg/ibm-sametime-9-complete-basic-features-installation-from-zero-to-hero-for-domino-ldap-version-10

Really ?? 970 pages? .. and this is only basic features.

OK, if the product was a rocket going to the Moon, this might be a appropriate sized slideshow.

Sametime is living in the past and has just become way too bloated and complicated

Anyway most organizations will most likely be happier with a simpler and cheaper (free) solution.

A secure chat server like Openfire. It installs and configures in less than 10 min. can be used with LDAP (Domino). Has a Java API, a chat client, a web and mobile client.
Has web video conferencing (webRTC) via a plugin, connects to a Open Source PBX like Asteriks and more...

just sayin'....

Published by: Jesper B. Kiær at 10-11-2013 22:46:00 Full Post

Sådan kommer du på Danske Bank Erhverv med NEMID på trods af Java problemer.
For at kunne komme på Danske Bank Erhverv er du nødt til at ændre på opsætning af Java midlertidigt.


Åben Control Panel.

Vælg Java



Gå til "Security" fanebladet og sænk "Security Level" til Medium


Når NEMID har løst deres problemer skal du gå tilbage og hæve sikkerhedsniveauet igen til High

Published by: Jesper B. Kiær at 17-10-2013 13:45:01 Full Post

The classic recycle design pattern is flawed in some document iterations
As we all know you need to recycle your Domino Objects in Java to free up the back-end C++ objects, or your server will crash in the end.


People in general use the same pattern when iterating through documents.

Something like this:


Document doc = view.getFirstDocument();
while (doc != null) {
     Document tmpdoc = view.getNextDocument(doc);
     doc.recycle();
     doc = tmpdoc;
}


This will work in must situations, but in at least one situation you will get a serious NotesException:
"Object has been removed or recycled"

An example showing the issue
To prove this point I will show you an example.

I have created a simple demo database containing a few documents to illustrate the issues.
The documents contain only 2 items Country and Region.
Country is a multi-value field since a region can contain several countries.
The database contains a simple view with 3 columns


The first column has the property "Show multiple values as separate values" set so each entry in the documents item will show up in its own row
This is handy and a VERY useful feature, especially for lookups in the view.


There are only 4 documents in the database, but the view has 6 entries since one document has an Country item with 3 values.
The very important thing to notice is Norway and Sweden are both the same document.
To illustrate this I have added a third column which shows the NoteID for the document.

So what happens if the normal recycle pattern is used?

....
Document doc = view.getFirstDocument();
int counter = 1;
System.out.println("\nTest View. Getting columnValues from documents using getNextDocumnt iteration");
System.out.println("-----------------------------------------------------------------------");
while (doc != null) {
Vector cv = doc.getColumnValues();
if (cv.get(0).getClass().getName().endsWith("String")) {
System.out.println(counter++ +". String doc: " + cv.get(0)
+ "-" + cv.get(1));
} else if (cv.get(0).getClass().getName().endsWith("Vector")) {
Vector fieldVector = ((Vector) cv.get(0));
System.out.println(counter++ + ". Vector doc: " + fieldVector.get(0)+"-" + cv.get(1));
}
Document tmpDoc = view.getNextDocument(doc);
doc.recycle();
doc = tmpDoc;
}
....



You will get a NotesException! Surprisingly since this pattern has always worked.

When the document iteration gets to the Sweden document it fails Why?

The problem is that Norway and Sweden are the same document.
So instead of getting hold of a new document as it normally would it, getNextdocument assigns tmpDoc to the same doc once again.

Document tmpDoc = view.getNextDocument(doc);
doc.recycle();
doc = tmpDoc;


Since doc now gets recycled, so does tmpdoc since they point to the same backend document.
So when I try to use the doc document it fails with a NotesException "Object has been removed or recyled" ...which is true :-)

The fix
The workaround to this is very simple, do not recycle if two consecutive documents are the same document.

if (doc!=tmpDoc) {
doc.recycle();
}


What about Entries?
You may be safe here but as I will show in my next blog, there is a bug in ViewEntryCollections that will give you wrong values!

Lesson learned
So the lesson learned here is that if a column has "Show multiple values as separate values" set, you need to use the recycle workaround if you iterate with documents
Yes, the example here is of course a special case where two consecutive entries are the same document, and you may never have run in to it, ....but you might the next time :-)

UPDATE
In the comments to this blorentry Karsten Lehmann (who's work I respect a lot!) has questioned the workaround claiming that the recycle will never be called.
So to show it IS actually being called I have inserted two simple print statements.

if (tmpDoc != null) {
if (doc!=tmpDoc) {
System.out.println("Recycling");
doc.recycle();
}else{
System.out.println("No Recycling");
}
}


and this gives


Which shows it recycles exactly as intended.

Published by: Jesper B. Kiær at 26-04-2013 16:34:00 Full Post