On Jun 16, 2009, at 6:52 AM, GrayHat wrote: >>>> Maybe I am wrong :) > >>> No, you are not wrong. The coding is the simple part in some > decisions >>> we have to do. We are trying to keep V1 and V2 as code-compatible as >>> possible because we are only two developers. Going for a fork in V1 >>> only because very few users are running V1 with big logfiles is >>> something we do not lighthearted. V2 is the normal update part we >>> provide, and there is no problem in V2 with big logfiles because of >>> multithreading. I have to pay attention not to be sucked into >>> inventing everything in V1 again we have already in V2. > >> IMO things should be kept as simple as possible in V1. > > Well... the idea was exactly to make things simple :) see, using a > "special" file (or DB) to log rejected/discarded messages would > imHo help generating a "blockreport" in a short time and without > "overloading" the system... the classic "raindrop path" coding idea
If I understand this issue correctly, ASSP can have a problem where it will degrade in performance when a parse of a certain log file happens, if that log file meets certain criteria. The proposed solution was to fork a process off and let it do it's work in the background, not affecting the main core of ASSP work. Is that a more or less correct evaluation? Since there was some trepidation about forking as a result of ill behavior and support on Windows, what about considering letting entirely new programs deal with this? I have noticed that all work seems to happen in assp.pl. What are the downsides, or reasons that something like sqlite, a totally open, super fast, and easily portable local database system be used for storing these logs. At that point, analytics, graphs, charts, and processing on any of that data becomes trivial, and many other users can then build untold interfaces to data. Further, small scheduled scripts can then work as separate apps/ processes on the sqlite database, being completely isolated form the work ASSP needs to do. ASSP seems to me, it is a really great proxy, and should aspire to be mostly a proxy, at least in 1.5. Whatever else it needs to do, could be done outside the scope of ASSP. Greylisting is perhaps the one thing that would need to be kept core to ASSP, but the greylisting db certainly would not hurt to be put into a database as well. I believe that of most languages, perl is way up there on strength and ability to process text files and manipulate that data, but there will always come a point where with a email proxy, text file data has chances of becoming large. * Does this hanging issue happen on *nix, or is this just a windows issue? I would wager, the way in which *nix's deal with scheduling load, this may not even be an issue outside of Windows. Thanks for any more detail. -- Scott * If you contact me off list replace talklists@ with scott@ * ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
