Re: [St's TB Annoyances] thebat.IPC
Hallo St, On Fri, 27 Aug 2004 02:25:04 +0200GMT (27-8-2004, 2:25 +0200, where I live), you wrote: AFAIK you're running TB permanently (and at very short poll intervalls). SMN True - although 30 seconds isn't what I would consider to be _very_ short SMN intervals. Or? But nevertheless it is extremely short. When a server has multiple users with such a polling frequency it's bound to have problems (server side), TB is a bit (too, IMO) vulnerable for server sided problems. But what you're describing is that it might cause problems client side too. I had several users that were polling my server once a minute. I've convinced all of them to drop that to once every five minutes. And that didn't hurt the stability of my (non dedicated) server. Furthermore I think that a polling frequency can be calculated by the mailflow you're receiving. Your polls should have an average of one mail that they're collecting. That means 8640 mails a month should justify polling every five minutes. For 86400 that would correspond to 30 seconds and if that's the case, you shouldn't let TB run unattended or you won't have the time to read all of them. ;-) -- Groetjes, Roelof The Bat! 2.13 Lucky Beta/7 Windows XP 5.1 Build 2600 Service Pack 1 1 pop3 account, server on LAN Disclaimer: Any opinion stated in this message is not necessarily shared by my budgies or rabbits. Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
Re: [St's TB Annoyances] thebat.IPC
Alexander S. Kunz: AFAIK you're running TB permanently (and at very short poll intervalls). St: True - although 30 seconds isn't what I would consider to be _very_ short intervals. Or? Roelof Otten: But nevertheless it is extremely short. When a server has multiple users with such a polling frequency it's bound to have problems (server side), TB is a bit (too, IMO) vulnerable for server sided problems. But what you're describing is that it might cause problems client side too. I had several users that were polling my server once a minute. I've convinced all of them to drop that to once every five minutes. And that didn't hurt the stability of my (non dedicated) server. I feel you are missing the point. My grief is not about TB not reaching the mail server. When I said 30 seconds isn't what I would consider to be _very_ short intervals I meant poll intervals between each time TB is checking thebat.IPC! Remember, TB is actually checking thebat.IPC every 10th second (unless the countdown is reset by starting a second TB). Hence, if TB is checking thebat.IPC every 10th second, then 30 seconds isn't what I would consider to be _very_ short intervals. My topic is about TB eventually failing to _read_ and execute thebat.IPC. -- St Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
Re: [St's TB Annoyances] thebat.IPC
Alexander S. Kunz: AFAIK you're running TB permanently (and at very short poll intervalls). True - although 30 seconds isn't what I would consider to be _very_ short intervals. Or? Alexander S. Kunz: An environment that, as you said some weeks ago, requires you to restart TB now and then. You could do that with a scheduled /EXIT when you're in doubt if the .IPC file is still interpreted, couldn't you? Unfortunately, no! /EXIT relies on thebat.IPC - thus if TB ignore reading thebat.IPC then /EXIT won't work either! If TB had a last resort - like if a file force.exit.thebat.doh exist in the program directory then TB would exit. My applications do have protections against a dead loop as such as the system will reboot and restart from where TB ignored thebat.IPC. But I feel it is unacceptable having to reboot every 7-10 minutes. I am trying to tune the shit, and already I have produced protections of DOS'ing TB. After letting FileMon monitor for a while, it is revealed that TB check thebat.IPC every 10th seconds. However, each time one is running a second TB (with or without IPC commands) the primary TB will sync up to the secondary TB. If, for example, TB was checking thebat.IPC at times 16:03:05 16:03:15 16:03:25 16:03:35 and you start a second TB at 16:03:38, that second TB would have the primary TB to check thebat.IPC right away - and subsequent checkings of thebat.IPC would then time to for example 16:03:49 16:03:59 16:04:09 16:04:19 and so on. When it comes to what one can put into the thebat.IPC TB is pretty forgiving, but apparently commands that isn't supported won't be executed. Put a fake command (ie. /DOH) into thebat.IPC and TB will read and process the file - but nothing will happen as a result of that /DOH command. I tried three methods to have TB process IPC-commends. After some testing, I fortunately found a way of doing it and that I have found to be stable with my software - even at a pretty short poll intervals. The most stable method of executing IPC-commands is to write the commands into a batch file. A batch file is described in the Help-file: If you need to execute a lot of commands many times, the /BATCH command is a life saver. This command allows the execution of multiple commands defined in a text file; each command being placed in one line. I find that doing so makes running IPC-commands stable. I have tested for some days now, and it is stable - TB hasn't failed once! Just for the record, the following two methods are totally unstable and I can not recommend them: 1) Sending each command directly from th command line - like 16:05:00 - C:\Program Files\The Bat!\TheBat.EXE /MAILU=[snip] 16:05:03 - C:\Program Files\The Bat!\TheBat.EXE /SEND* etc. (commands /MAILU and /SEND are for the example only. TB will pretty soon (in minutes) stop checking thebat.IPC - useless! It do seems TB is choked, but the above may even happen even though the intervals are longer than 30 seconds - maybe even after minutes between each action! So there is some condition that makes TB stop checking thebat.IPC. 2) Update/composing thebat.IPC directly at a time TB is not checking it - like 16:05:00 - TB is polling thebat.IPC 16:05:05 - writing IPC-commands to thebat.IPC 16:05:10 - TB is polling thebat.IPC Again, TB will pretty soon (in minutes) stop checking thebat.IPC. One should assume it would be safe to write to the thebat.IPC as TB is not occupying it. Yet, this method is proven just as unstable as with the first method - and again it's useless! I have no idea why the latter two methods eventually fail. Stick to writing to a secondary batch file (thebat.TXT etc.) point to it from the command line. As for /EXIT that fails when TB fails to check thebat.IPC: Alexander S. Kunz: ** You. Do. Not. Need. The. IPC. File. ** You do! /EXIT won't work when TB stops checking thebat.IPC - because (as you later found out): TB itself writes the .IPC file when you access it via the commandline?!?. Yes, it does - I have always said that (or at least implied it strongly)! :) It was crucial in the discussion and is a major reason for topic of [St's TB Annoyances] thebat.IPC. BTW - thru the batch file method I hav been able to produce a stable fix for the problem I outlined in [St's TB Annoyances] Periodical Checking (of mail). -- St Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
[St's TB Annoyances] thebat.IPC
From the TB help file: For those who are familiar with programming, here's a handy hint: The Bat! checks a file called TheBat.IPC which is located in the same directory in which The Bat! executable (TheBat.exe) file is located. Within this text file, each line represents one command that can be executed by the program, so you can write commands to this file directly and control The Bat! on your PC even over a local network. Note that TheBat.IPC is deleted as soon as all commands from it have been executed, so if this file does not exist, you will have to create it to make use of it. BUT: Every now and then TB apparently fails to read this file, and from then on it simply ignores further checking thebat.IPC. Unless you restart TB, it won't check thebat.IPC. Now, exactly how do you send TB new commands (like the rather liberating /EXIT (to restart)) when TB fails to read the file that contains the request? The help file further states: Note that you can run only one copy of The Bat! on your PC at one time, but if you try to start another copy of The Bat!, all Command Line parameters will be seamlessly passed to the running copy of the program and executed. Apparently, if TB failes to read the IPC-file just _once_, some error code instructs TB to give a dudu about trying to read the file later on! And exactly how do you send TB that IPC command when TB fails to read the file that contains the request!?! -- St Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
Re: [St's TB Annoyances] thebat.IPC
Hello St - Musaic.Net, 14-Aug-2004 16:17, you wrote: exactly how do you send TB that IPC command when TB fails to read the file that contains the request!?! You don't send an IPC command, you use the command line which passes its commands to the running TB instance. That is in the helpfile, too. -- Best regards, Alexander I think that God in creating man somewhat overestimated his ability. -- Oscar Wilde How true... Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
Re: [St's TB Annoyances] thebat.IPC
St: ...exactly how do you send TB that IPC command when TB fails to read the file that contains the request!?! Alexander S. Kunz: You don't send an IPC command, you use the command line which passes its commands to the running TB instance. That is in the helpfile, too. Don't be too confused by my use of the word send. I am aware of the use of command line thingy... I know that one is supposed to send (or process / invoke) IPC commands by starting secondary TB's from the command line; ie. C:\Program Files\The Bat!\TheBat.EXE /EXIT etc. My point is this: For no reason, TB may at any time simply stop looking for thebat.IPC - and thus TB won't know of the _future_ commands you send it (by the way of the command line). (In fact, you don't even have to use _command_line_ method - you may simply create the file (thebat.IPC) manually - just make sure the syntax is correct and here we go.) -- St Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
Re: [St's TB Annoyances] thebat.IPC
Hello St - Musaic.Net, 14-Aug-2004 17:35, you wrote: My point is this: For no reason, TB may at any time simply stop looking for thebat.IPC - and thus TB won't know of the _future_ commands you send it (by the way of the command line). Have you investigated why this is happening? SysInternals FileMon may be of help. Maybe your on-access virus scanner blocks the file, something like that? (In fact, you don't even have to use _command_line_ method - you may simply create the file (thebat.IPC) manually - just make sure the syntax is correct and here we go.) AFAIK you're running TB permanently (and at very short poll intervalls). An environment that, as you said some weeks ago, requires you to restart TB now and then. You could do that with a scheduled /EXIT when you're in doubt if the .IPC file is still interpreted, couldn't you? -- Best regards, Alexander There is no reason anyone would want a computer in their home. -- Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977 Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
Re: [St's TB Annoyances] thebat.IPC
Alexander S. Kunz: Have you investigated why this is happening? SysInternals FileMon may be of help. Maybe your on-access virus scanner blocks the file, something like that? Funny that you ask - I am currently running FileMon here (with an exclusive logging of thebat.IPC-accesses. Whatever is trying to access the file will be logged. BUT I am also supposed to be present in a BBQ Party - so I will have to return later to this list about my findings... -- St Current version is 2.12.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
