>won't be a somewhat >better approach having the web GUI running in a separate thread ?
Yes Yes Yes ! >well... the GUI thread may also handle this... although I'm not sure it >would be possible since the thread would then need to access data/infos which >sit inside the main process... hmmm.... This is the realy problem. I want to have such a WebThread and my early plans (2007/2008) have seen it. The real problem is the shutdown and restart - which is impossible to do outside the main thread and having control on it. Some other task are making some other trubble - how ever, at the moment the work that must be done to get a Web- and Logging thread is too much in relation to the small impact : >"in case one tries to edit a "big" file". I think it would be much more easy, to switch the 'SMTP-connection-listening' to an other/extra thread - and keep Web and Stats in the MainThread. We need some news for the new releases - so let's keep this in mind. >workers (not just 1 and 4)... is it expected or it's something nasty >Jul-6-09 18:43:16 [Main_Thread] Info: Worker_4 : last sigoff in main, c:\assp\assp.pl, 21827, main::sigoffTry, 1, , , at Jul-6-09 18:29:12 1246897752.3445 - 21827 Jul-6-09 18:43:16 [Main_Thread] Info: Worker_4 : last sigon in main, c:\assp\assp.pl, 21865, main::sigonTry, 1, , , at Jul-6-09 18:29:12 1246897752.42027 - 21865 This looks like ClamAV is not responding - holding the socket in C-code and Perl is unable to get it out there ! Try to restart ClamAV - if no success - restart ASSP. Thomas "GrayHat" <gray...@gmx.net> 06.07.2009 18:44 Bitte antworten an GrayHat <gray...@gmx.net>; Bitte antworten an ASSP development mailing list <assp-test@lists.sourceforge.net> An "ASSP development mailing list" <assp-test@lists.sourceforge.net> Kopie Thema Re: [Assp-test] Antwort: Re: Antwort: Re: Antwort: Re: Antwort: Re: ASSP V2 -ready tobereleased on SF ? > but I thought that GUI request were server asynchronously so > the main ASSP loop (i.e. email serving) wasn't impacted by > webgui > Yes and No. The MainThread (MainLoop) does nothing else than listen on all > defined listeners and transfers SMTP connections to the workers before the > connection is accepted. So processing the mails, is asynchronously to the > GUI - getting new connections is not. hmm... I see now; I thought the whole network I/O (listen/accept) was handled by a single thread which then was passing the connections to the workers but now I see it's structured in a different way... ok, at least now I know :) > In addition to that, he is monitoring the SMTP-workers (not realy much > to do), doing the output to STDOUT,STDERR and SYSLOG - and is > doing all the Web-Stuff. For normal web actions this does not matter, > because only the action buttons are doing requests to the web port. Yes, once the HTML has been sent to the client browser ASSP will get back to its regular duty and will just be "called" again in case one hits the "apply" button or one of the "edit" ones or in any case clicks on a link which generates a new web request; yet, in case one tries to edit a "big" file ASSP may look "stuck" for a while... won't be a somewhat better approach having the web GUI running in a separate thread ? (just thinking loud, nothing more !) > Only the autorefresh "SMTP connection" screen will slow down the > MainThread (and Workers) more as a bit, because this screen > refreshes every second and the request impacts also to all Workers, > because they have to collect and to transfer detail status information > to the MainThread. The autorefresh in "Maillog Tail" and the "Worker > Status" will not impact so/too much. well... the GUI thread may also handle this... although I'm not sure it would be possible since the thread would then need to access data/infos which sit inside the main process... hmmm.... > All other actions, like DBImport/DBExport, LDAPCrossCheck, > BlockReports and some more, that could be initiated by the > GUI are transfered to the MaintThread (10000). crisp and clear, thanks :) ! Uh... and btw v2 is still happily running on that other system... ok, it has plenty of RAM and CPU power now and that machine hasn't so much connections but it seems to be ok; will leave it running and we'll see what tomorrow will bring :D About the SF release... I think that it may be a good idea to start by releasing a first v2 as a "pre-release/beta" version and to add to it some "release notes" (see the button in the SF download interface) containing infos about all the needed pre-requisites that is, not just perl version and modules but also a bare minimal h/w config (ram, disk space, cpu...) so that people won't try to install it on a 486sx with 640Kb RAM and then come back screaming since "it's not working" <grin> ------------------------------------------------------------------------------ _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test DISCLAIMER: ******************************************************* This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the individual to whom it is addressed. This email was multiple times scanned for viruses. There should be no known virus in this email! ******************************************************* ------------------------------------------------------------------------------ _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
