The server was upgraded to 6.5 recently. It is an inbound smtp server which was working correctly for a few weeks after the upgrade. Now at night, when any task runs that requires a quitting of the router results in the router never fully quitting. Entering in another “tell router quit” command does not bring it down either. I end up having to reboot the server. When the server is functioning during the day I can manually stop and restart the router without issue. I first noticed the problem started to happen right after the server’s mailboxes were compacting. The log files would say that the router was waiting on the router quitting but it never happens. We disabled the compacting just to see if that would solve it. Well now in the morning when the deletion stubs are being purged from the mailboxes, the router is again attempting to stop and quit the transfer queues but again the router never fully quits causing no inbound mail to route at all. Has anyone had any similar problems with this? I really dont like to have to log into the server every morning to reboot and its becoming a daily task now. Any help would be apprecitated.
Subject: When a scheduled task is run at night (compact), the router does not fully quit
Well the router only needs to be turned off to compact the mail.box. If I compact a database (like the log.nsf) I am not forced to stop the router.
In fact my R6.5 server has been running 45 days with it doing a full server compact and email is still routed. (No router task stop).
I question if there is something else wrong. To me it is a coincidence that that it happens as the compact task is running. I think maybe the resources are running low on the box and that is why is it not shutting down as quickly as you hoped.
HTH – Cheers
Subject: RE: When a scheduled task is run at night (compact), the router does not fully quit
The box is a monster, resources aren’t the problem. Also the inbound mail boxes are compacted nightly at 1 AM everyday (this is done as something IBM suggests) and I will come in at 8 AM and the router still has not finished quitting yet. Its immediately after any automatic or scheduled task that requires a router quit or a deactivation of xfer threads. Take a look as these log lines below (note that the last lines you see opening and closing sessions for my servers repeat over and over again until I intervene by quitting the domino service.)If I type in “tell router quit” at the console nothing happens. If I type in “load router” domino tells me the “router is running and awaiting on the pending queues to quit” I had the tell router compact command disabled and the next few days the problem starts right from that line “PM Router: Purging deletion stubs from mailbox file mail1.box” So now that I look at it, its probably not the compact command that is causing it, but the deactivation of the xfer threads which never seem to fully deactivate. In fact the next few night’s log files look exactly how you see them below without the “tell router compact” line
01/13/2004 08:30:34 PM Router: Transfer queue to server VMSINFO.COM is not ready to retry until 01/13/2004 08:35:39 PM
tell router compact
01/13/2004 08:30:38 PM Router: Purging deletion stubs from mailbox file mail1.box
01/13/2004 08:30:38 PM Router: Purging deletion stubs from mailbox file mail2.box
01/13/2004 08:30:38 PM Router: Purging deletion stubs from mailbox file mail3.box
01/13/2004 08:30:38 PM Router: Purging deletion stubs from mailbox file mail4.box
01/13/2004 08:30:38 PM Router: Purging deletion stubs from mailbox file mail5.box
01/13/2004 08:30:38 PM Router: Freeing transfer queues (0)
01/13/2004 08:30:38 PM Router: Waiting for 25 transfer thread(s) to quit. Currently 0 are inactive
01/13/2004 08:30:38 PM Router: Deactivating transfer thread 0000000C; 1 inactive threads
01/13/2004 08:30:38 PM Router: Deactivating transfer thread 0000001F; 2 inactive threads
01/13/2004 08:30:38 PM Router: Deactivating transfer thread 00000020; 3 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000006; 4 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000009; 5 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000007; 6 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 0000001D; 7 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000018; 8 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000015; 9 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000016; 10 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 0000000F; 12 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000022; 11 inactive threads
01/13/2004 08:30:39 PM Router: Deactivating transfer thread 00000014; 13 inactive threads
01/13/2004 08:30:40 PM Router: Deactivating transfer thread 0000000D; 14 inactive threads
01/13/2004 08:31:46 PM Closed session for DONYCMS3/CushWake|Databases accessed: 1 Documents read: 0 Documents written: 1
01/13/2004 08:32:31 PM Opened session for DONYCMS3/CushWake (Release 5)
01/13/2004 08:32:31 PM Closed session for DONYCMS3/CushWake|Databases accessed: 1 Documents read: 0 Documents written: 1
01/13/2004 08:32:32 PM Opened session for DONYCHB2/CushWake (Release 6.5)
01/13/2004 08:32:32 PM Closed session for DONYCHB2/CushWake|Databases accessed: 2 Documents read: 0 Documents written: 0
01/13/2004 08:35:06 PM Opened session for DONYCMH1/CushWake (Release 6.5)
01/13/2004 08:35:06 PM Closed session for DONYCMH1/CushWake|Databases accessed: 1 Documents read: 0 Documents written: 1
01/13/2004 08:35:14 PM Opened session for DOMEXMS1/CushWake (Release 5)
01/13/2004 08:35:15 PM Closed session for DOMEXMS1/CushWake|Databases accessed: 1 Documents read: 0 Documents written: 1
01/13/2004 08:35:51 PM Opened session for DONYCMS3/CushWake (Release 5)
01/13/2004 08:35:51 PM Closed session for DONYCMS3/CushWake|Databases accessed: 1 Documents read: 0 Documents written: 1
01/13/2004 08:37:20 PM Opened session for DONJXMS1/CushWake (Release 5)
Subject: RE: When a scheduled task is run at night (compact), the router does not fully quit
You’ve have my interest, but where does it say for the recommend compact. Do you mean the servertasksat parameter in the notes ini?
When you do a type ‘load compact’ at the console. The database types NOT compacted are .NTF and .BOX.
In fact on my server log show entries that there is a separate process running at 4 AM every day compacting the mail.box database – it alone stops and start the router task.
So I am not following how the compact task is impacting the router task.
I guess I would not run it for a night and see if the server is having problems the next morning.
Subject: RE: When a scheduled task is run at night (compact), the router does not fully quit
I had the same problem on R5 mail server.Finally we was forced to use MailCompactDisabled=1
and do all mailX.box compaction by scheduled task