In the server console, I see at least 20 pages of 30 entries of tasks for DIIOP all of them “providing service to user XXXXXXXXXXXXX”
We have a Java application that fetches information in a Domino database, but the programmer assures me that the connection is disconnected after every data fetch. Why do I have so many tasks running and is it a problem for the server?
How do I go about reducing this without forcing a periodic reboot of the server?
The server is an iSeries V5R3M0
Thanks,
Luc Millette
Subject: 600+ DIIOP tasks
So long from the problem you found, and i think you may have found the why .Still I has some word to say, hope it will help others when they search such problem.
I’ve occured the issue as you said , but really I’m sure call the session.recycle() for releasing the server connection.
At last I found that my code has a call like this:
session.getDatabase(server,nsfpath)
The notes document has said if you want to open a nsf on a server in session’s environment , you must use null. If you not use null but the server hostname or ip,it will create another session for the localsystem user (some format like “hostname/org”)and whatever you call recycle for your session, the new session won’t be closed. So the amount of such session increased, It may be released at a certain time but not the timeout in DIIOP config
Actually I also found the DIIOP session seems not show the user in command “show users” (without any paramter)
Subject: 600+ DIIOP tasks
What exactly do you mean by "600+ tasks’? Are the 600 DIIOP jobs running? Or are there 600 threads running under the DIIOP job? What is the 600 number based on?
Subject: RE: 600+ DIIOP tasks
Well if I look at the tasks page in the administrator I see 600 times the DIIOP task.
I can’t check with the programmer unfortunately, because she’s a consultant 
Oh well … thanks for the response.
Subject: Two suggestions
I can make two suggestions.
If you want to see if the application is using Session.recycle() you can set the notes.ini variable DIIOP_DEBUG_INVOKE=1
This will cause the server to generate messages like this:
[0A38:0022-0E50] 04/18/2005 10:56:38.16 AM ReqDone> OS0006275F2 createSession 2 ms
[0A38:0022-0F40] 04/18/2005 10:56:55.52 AM ReqDone> DC00064364C-SN000643648 recycle 2 ms
[0A38:0022-0B54] 04/18/2005 10:56:55.94 AM ReqDone> VW00064364B-SN000643648 recycle 423 ms
[0A38:0022-0B54] 04/18/2005 10:56:55.98 AM ReqDone> DB00064364A-SN000643648 recycle 4 ms
To confirm that the client application is recycling the session you can look for messages that has the following text. Some of the output changes every time, but look for the highlighted pieces:
[0A38:0022-0B54] 04/18/2005 10:56:55.98 AM ReqDone> SN00064364A-SN000643648 recycle 4 ms
If you don’t find messages like this then sessions are not being recycled and it might be necessary to change the program.
The second suggestion is to take a look at a server document setting. DIIOP will automatically recycle sessions after they have been inactive for some configured amount of time. That time is specified in the server document, look under the Internet Protocols tab and then the DIIOP tab. You could change the setting Idle session timeout: to something more reasonable for your environment. The default is 60 minutes.
Regards, Steve Nikopoulos
Subject: RE: Two suggestions
Thanks for your post Steve. I already determined that we need to lower the DIIOP session timeout to 20 or 30 minutes. Currently, we have about 1500 connections that remain idle for 60 minutes. I used tell diiop show users d to extract the info to a text file.
I also read about increasing the log detail for DIIOP and I think we’ll do that next … if we put it to level 4 (logs everything DIIOP does) for a few hours, It might give us a better idea what is happening.
I’ll look for your suggestions once our logging is better. I’m almost SURE the application doesn’t use the recycle method. I don’t know what’s used, but I’m sure it isn’t recycle if they’re creating a new connection every time they do a database read/write.
Thanks for helping,
Luc
Subject: using Session.recycle() ?
When we had a similar symptom here; the problem seemed to clear up when the developer added a line to recycle the session object at the bottom of the loop. He was initializing the session variable at the top of the same loop, but that wasn’t closing the instance initialized on the previous pass. Your programmer is probably right, but it’s worth double-checking.