Performance issues in logview4net
I recently got a message from a user who had performance issues with logview4net when using the pause function in combination with lots of incoming events. Since pause is probably mostly used in situations when there are lots of events I guess more users than Bill and I have noticed it before. I have two cores on my main machine so I usually just let it be until logview4net has recovered by it self. The problem is that almost all processing of an event takes place when it is time to display it, not when it is received. When running in normal mode this is ok, but when coming back from pause mode this places a big burden on the display thread.
I’ve made a change today so that the application does all processing of an event, except the coloring, before it is sent to the cache when in pause mode. That way the processor utilization should be almost the same when in pause mode as when running normally.
I will make the new release in the first week of January to get the nice version number 8.01
Commercial licensing of open sourced applications
I am thinking of releasing logview4net under a commercial license as well as the BSD license I am using now. This would enable users in organizations that dislike open source to use the application anyway.
Besides the political issues I need something else to motivate an organization to pay for something that is given away for free. There is at least one new listener coming up and I could definitively release updates earlier to commercial users. I don’t like having to manage two code bases so the compiler savvy could always get the latest version from SourceForge. I guess I could include the source and documentation in the commercial package if someone wants to run the application without internet access. On that note I could offer email notification to commercial customers when there are new updates.
Do you have any thoughts on this?
Big ups to Trent
Trent at The Simple Dollar removed his Adsense ads because they often showed ads that were in contrast to the content of his blog.
I just want to give him some cred for being strong in his principles.
I have some ads but the click through rate is so small I should probably do something else with that space. It is up for sale for almost any immoral purposes if the pay is good enough.
A formal build-and-deploy process becomes essential.
I’m reading Pro BizTalk 2006 by Apress and a section in the chapter about setting up a new BizTalk project made me a little upset.
The author thinks it is a disadvantage that: ‘A formal build-and-deploy process becomes essential.‘
WTF; in an organization big enough to think about, and afford, BizTalk I would say that a formal build-and-deploy process is a prerequisite. Since BizTalk is a lot, if not all, about integrating different systems and organizations having a strict configuration management is essential to keep the cost down and the quality up.
It is a nightmare to find, and correct, errors that exists because there is version inconsistency between the partners in an integration project. I find that having a formal build-and-deploy process is almost essential even for a small one man project. I’d even say it’s more important the more infrequent there is work done on a small project.
On a software project, of any kind, there has to be a formal build-and-deploy process in place as soon as there is artifacts to be delivered from a developer.
Application launcher
I’m inventing a wheel today.
My current project needs to update itself over the Internet but I don’t want to have a Click Once install. The launcher will incorporate the licensing scheme I created for jsiPodFetch and most of the updating functionality from jsiPodFetch and logview4net.
The launcher might be installed via Click Once, but I think it will need a little to much privileges to run in the sandbox.
I run the launcher from the standard Program Files location where it ends up after installation. Then I create a folder under LocalApplicationData and copy the ‘real’ binaries to it. This way I can download updated files and update the application before I actually execute it. I can’t update the launcher though so I haven’t really decided how much functionality I should put in it.
Now that I think about it I could have a pluggable launcher pipeline. Just after the launcher has downloaded and extracted the package it could look for pipeline components in the assemblies it just downloaded. That way I can keep the launcher to a minimum and yet have it manage licensing and things like that.
Previously I have downloaded a new install package when I wanted to update my applications, but these users will probably not know what to do with an installer so I’d really like to keep it transparent to the user.
New release of logview4net 7.49
Yesterday I slipped out a new version of logview4net. It was just a very small bugfix. I had lost the checkbox for adding a filename to the listener prefix in the settings for the folder listener.
Big ups to Paul who told me about it.
