IBM Domino and DIIOP - not quit doing what it is supposed to.
I am using DIIOP to have remote session with a Domino server, because using Java agent just gave to many issues with some external libraries.
While DIIOP may not be the fastest way to work with data on a IBM Domino server, it usually does the job...well sort of..
I've just found out when using richtextitem.embedobject the name parameter of the file does not work, so the attachment gets this reeeeaaally long name ...including the file path.
Also I needed to create a text file on the server so why not use the Stream class? Unfortunately I got a lot of errors until I found out the Stream was actually not trying to write the file on the Domino server, but my local PC??
If I wanted to write to my local file system I would probably not use a REMOTE DIIOP session! ..capisce IBM?
Maven - how to get dependency JAR files in build too
Maven may be smart to some ....but it is also a bloody XML nightmare, where many things can go wrong ...(or maybe it just me being stupid)
Just a reminder to myself....when I want to have dependency JAR files in build too , add this to pom.xml file
<!-- <classpathPrefix>lib</classpathPrefix> -->
<!-- <mainClass>test.org.Cliente</mainClass> -->
IBM Domino, a very annoying performance issue now SOLVED
For the past years a customer of mine has had IBM Domino performance issues with a Domino Server.
The issue concerned was really felt when working with attachments.
The company has small offices around the world, so we use SmartUpgrade (which in general works well) to manage Notes Feature Pack upgrades.
We attach the Feature Pack as an attachment in the SmartUpgrade database and use a Policy to push it to users.
Normally this is very fast, but for one server it would maybe take 5 hours to download the file.
The download would start at a decent speed and then only get slower and slower and in the end literally only move a few bytes at the time.
We tried "everything" ...even moving to newer faster hardware did not make any change.
The server is a Windows 2012 R2 server with Domino 9.0.1. FP8 in a Domino cluster. The other server is Linux server which did not have the issue.
The relevant difference between the two servers Domino in the Notes.ini configuration, was the setting for TCP.
The customer use encryption and compression on the Notes TCP connection
The Windows server had: TCPIP=TCP,0,15,0,,45088
The Linux server had: TCPIP=TCP, 0, 15, 0,,32800
If looked at the documentation for TCP setting it says:
|The TCPIP port line can contain up to six arguments as described below, with the first position numbered as position 0.|
argv Driver name
argv Adapter number (unused)
argv Requested number of sessions (unused)
argv Data buffer size to use. If the value is 0, the default size is used. Default sizes are different for different port drivers, as follows:
argv Number of network buffers to preallocate (unused)
argv Port flags, as follows:
0 X 8000 Encryption is enabled
0 X 0020 Compression is requested
Since we use Compression and Encryption of the connection we should have 8020 in hexadecimal for last parameter, which in decimal is 32800.
That is value we had on the fast Linux server. After changing the value on the Windows server to
TCPIP=TCP, 0, 15, 0,,32800
the network was much faster and SmartUpgrade became just as fast as on the Linux server :-)
The big question is why does the Domino installer suggest TCPIP=TCP,0,15,0,,45088 ??
and what are the undocumented Port flags used in this scenario?
IBM Domino lessons learned from using the new FP8 feature of having the view index outside the NSF database (NDX)
At a customer today I wanted to implemented the new IBM Domino feature of having the view index outside the NSF.
First I upgraded to FP8 IF3, then I updated notes.ini from the configuration document with the new setting NIFNSFEnable=1 and restarted the server.
I then wanted to start carefully with one database only ...with something like "load compact -c -nifnsf on databasename.nsf".
Unfortunately I misspelled the database path and hit enter. To my surprise the Domino server did not just report back in the console that the database could not be found, ...instead is started compacting on ALL DATABASES!
Not quit what I expected or wanted .... but I let it continue
Lesson learned...software does not always act as expected ...act accordingly..get you spelling in order!
I kept an eye on the compacting and I noticed that one big database (GB) just barely got touched only creating a small NDX file and the compacting moved on.
I am a little unsure what to expect now. My guess that it created some kind of "stub", because the database most likely was in use it could not compact it.
So I hope that when DBMT starts compacting it will finish the job....but I am not sure, may need to run the ""load compact -c -nifnsf " again.
Lesson learned ... it is always "fun" when software stops in the middle of doing something ...what is going to happen next?
OK this one i primarily my fault,... I got the great idea ..why not open the NDX file in the Domino Designer and have a look around?
Lesson learned... don't do that... your server will come to a grinding halt...
You are probably not meant poke around in a NDX database ;-)
I am sure there is plenty more to be learned...
Making "X-Forwarded-For" log feature IBM Domino FP8 actually work
In March I wrote about the new log feature in IBM Domino in connection with using a Reverse Proxy.
The issue is that you will always get the IP address of the Reverse Proxy in you HTTP log files and not the actual IP of the user.
This is what the HTTP header "X-Forwarded-For" is used for, however pre FP8 is was not supported on IBM Domino server.
In FP8 it is supported...but not documented.
Thanks to Vitor Pereira who (commented on my blog entry) created a PMR, we now have an answer how to get it working.
Add HTTP_LOG_ACCESS_XFORWARDED_FOR=1 to the servers notes.ini file, restart server and it works!
However if you using domlog.nsf for log data (which is fine for low traffic) you need to change the design to see the X-forwarded-for IP.
You would presume the item would be named something like "XForwardedFor", but no .. it is "ForwardedFor" ..or rather because it is misspelled it is "ForwaredFor" ;-)
New logging feature in IBM Domino FP8 when using Reverse Proxy - X-Forwarded-For
When using a Reverse Proxy (like Nginx) is in front of a IBM Domino web server you have the issue that the IP address of the client accessing the Domino web server is not forwarded to the log files on the Domino server.
What you get is the IP address of the Reverse Proxy instead...which is not very helpful.
This is normally fixed by the Reverse Proxy server adding a HTTP header field called "X-Forwarded-For" (XFF) which the web server then can log.
Unfortunately the IBM Domino web server will no log the "X-Forwarded-For" field..until FP8 it seems.
A long overdue request from 2010 apparently has been fulfilled in FP8.
My question is just ...how to enable? .. a notes.ini setting ?
(I presume the "X-Forward" is actually supposed to be X-Forwarded-For (?)