Code Site Limitations and Annoyances for Client Server and Service Development

[WARREN POSTMA]

So CodeSite is great. But there are major limitations and annoyances that I wanted to raise (raize?) because I am planning to remove codesite from all our products because of them, so I wanted to say what those are, and how we’re trying to use CodeSite but finding ourselves unable to do so.

1. CodeSite works great for desktop applications. The main dispatch data pipeline, in default use, is the WM_COPYDATA technique, which is great for non service applications.

2. CodeSite does not work well for service applications. If I understand the design correctly, operating as a background service (even having it REGISTERED as a background service, but not running) is a configuration flag that CodeSite is in TCP/IP mode not in WM_COPYDATA mode. However once I go into this mode, everything just fails. I have had no luck in getting it to work. Basically I end up with all desktop and service apps logging to nothing and nowhere and no log output anywhere either in the dispatcher log, or the live viewer.

3. CodeSite live viewer can’t be left always on on a non-developer machine, because the live viewer has no row limit or log rotation system. It becomes slow and seriously impacts the overall operation of the workstation on which it is left running. If the live viewer could be configured to simply keep the last N messages and auto-delete old messages, perhaps it would not become slow, or cause the systems that run it to slow down. We log a lot of stuff to codesite. Several hundred messages per second during key transaction processing tasks.

4. As far as I know, there is no way to use CodeSite for distributed TCP/IP network communications. If this is possible, then I will retract this limitation/annoyance. First we can’t get TCP/IP to work even locally, and secondly we’ve read cautions that TCP/IP performance (over TCP) is poor. What I wonder is if a higher performance named pipe solution might be possible (with a per client server station service forwarding queued logging data over TCP, when an active subscription to that station exists at the server).

These are offered in hopes that I am wrong on all the above points. I have sincerely tried to use CodeSite in a networked distributed client server network situation and have found it nearly impossible to use. It is fine as a single developer logging solution, for desktop apps on a developer pc. But I wish that it was more.

Warren Postma

• This topic was modified 4 years, 8 months ago by WARREN POSTMA.
• This topic was modified 4 years, 8 months ago by WARREN POSTMA.
• This topic was modified 4 years, 8 months ago by WARREN POSTMA.

[David Hoyle]

Warren,

I don’t know if this will help you but I use the following in a desktop application for logging to a file and the live view (if the dispatcher is running – for TCP/IP this needs to be manually started if I remember as it will not be started automatically under TCP/IP)

Const
  (** A constant for the log file extension. **)
  strLogExt = '.csl';
  (** A constant for the AppData environment variable. **)
  strAppDataEnviroVar = 'AppData';
  (** A constant for the Seasons Fall subdirectory under AppData. **)
  strSeasonFallDir = '\Season''s Fall\XER Tools\';
  (** ISO Date format for the CSL files. **)
  strFileDateFmt = ' yyyy-mm-dd';
Var
  (** A local private variable for the FileDestination CodeSiteLogger. **)
  FileDest: TCodeSiteDestination;
(** This section creates a file based CodeSite Logger for the applciation in the same directory. **)
Initialization
  FileDest := TCodeSiteDestination.Create(Nil);
  FileDest.LogFile.Active := True;
  FileDest.LogFile.FilePath := System.SysUtils.GetEnvironmentVariable(strAppDataEnviroVar) +
    strSeasonFallDir;
  FileDest.LogFile.FileName := ChangeFileExt(ExtractFileName(ParamStr(0)), 
    FormatDateTime(strFileDateFmt, Now()) + strLogExt);
  FileDest.Viewer.Active := True;
  CodeSite.Destination := FileDest;
  CodeSiteLogging.CodeSiteManager.ConnectUsingTcp();
(** Frees the file based logger. **)
Finalization
  FileDest.Free;
End.

• This reply was modified 4 years, 8 months ago by David Hoyle.

[David Hoyle]

I don’t know what’s happened to my first post but what account is your service running under and does that account have read/write access to the location you want to create the .csl file?

[Mika Koistinen]

Hi,
For 3. I might have a simple brute-force solution, which I use in my centralized codesite liveviewer machine: Just add a scheduled task to kill all live viewers. I do it during midnight

[Ray Konopka]

Hi Warren,

I am sorry to hear that you are having challenges with utilizing CodeSite for your products, but I do value your feedback. There are certainly limitations to the way CodeSite is currently designed with respect to services. This wasn’t always the case, but the fact is that logging from services with the current version of CodeSite is challenging because of the increased isolation that Microsoft has added to Windows.

When it comes to using CodeSite in a service, it all comes down to deciding how to run the CodeSite Dispatcher. There are two choices: 1. run the Dispatcher as a service, 2. run the Dispatcher as a desktop app. While it may appear that only option 1 is valid, but this not necessarily true. Each option has its advantages and disadvantages.

Running the Dispatcher as a service does make it a little easier for the CodeSite logging classes to communicate with the Dispatcher because the default transport method (wm_CopyData) can be used. Also, the Dispatcher service can be running even when no user is logged into the system. However, with the Dispatcher running in the service window station it is NOT possible to do Live Logging with the Dispatcher running as a service. That is because Windows prevents the Dispatcher from transporting CodeSite messages to the Live Viewer running on user’s desktop.

Running the Dispatcher as a desktop application will allow you to conduct Live Logging even from service apps. However, in order to do this, the transport method the CodeSite logging classes use to send their messages to the Dispatcher must be changed from wm_CopyData to TCP. This is accomplished by calling the ConnectUsingTcp() method either on the CodeSiteManager, or on the individual TCodeSiteLogger objects in your app. TCP messages are allowed to cross window station boundaries and thus the CodeSite Dispatcher will be able to receive CodeSite messages and then dispatch them to the Live Viewer and of course log files. Of course, in order for the Dispatcher to receive the TCP CodeSite messages, the appropriate port must be opened. Some customers have run into challenges in getting ports opened in a production environment for “logging”.

The reality is that in today’s environments, logging from services really is best served with the ability to allow the service itself to be able to log CodeSite messages directly to an isolated log file without requiring coordination from an external application. It should still be possible to send CodeSite message remotely, if desired, but again, it should all be handled within the service itself. This is, in fact, one of the major design goals I have been using while working on the next major release of CodeSite. I wish I could provide more concrete info and a release date, but I’m not ready to do that just yet.

In regards to item 3 in your list, I am intrigued by your comments. The Live Viewer has always been the primary developer tool for “debugging”. It was never intended to be used as a kind of CodeSite dashboard. But perhaps a CodeSite Dashboard is something that you would be interested in? I suppose a “Dashboard” mode could be added to the Live Viewer, but I’m wondering if it would be better to have a dedicated app. I am interested in learning more about how you are logging on non-developer machines. The Live Viewer is included in the CodeSite Tools as a convenience for on-demand Troubleshooting and not the usual method for capturing logging data–most end users do NOT want to see a logging window. Are you conducting File Logging along with Live Logging in your apps?

In regards to item 4, it is possible to send CodeSite messages to remote computers. This involves setting the CodeSiteManager.DefaultDestination or the Destination property of an individual CodeSite logger. The CodeSite Help does provide information on how to setup the subproperties of the destination properties. The key is that the CodeSite Dispatcher needs to be running on the local machine AND the remote machine.

I hope this helps answer some of your questions and concerns, and thanks again for your feedback.

Ray

[Bob Grimes]

Hi Ray, I know this is old, but I’m curious about this quote of yours:

“The reality is that in today’s environments, logging from services really is best served with the ability to allow the service itself to be able to log CodeSite messages directly to an isolated log file without requiring coordination from an external application. It should still be possible to send CodeSite message remotely, if desired, but again, it should all be handled within the service itself. This is, in fact, one of the major design goals I have been using while working on the next major release of CodeSite. I wish I could provide more concrete info and a release date, but I’m not ready to do that just yet.”

Has this capability come to fruition? Is it in the current release? Just wondering, as I’ve got a service app that I need to update in the near future, and I’m thinking I’d like to use CodeSite for it…

Thanks!

[Ray Konopka]

Hi Bob,

The functionality described above is indeed a central focal point of CodeSite 6. A release date for CS6 has not been announced, but I am hopeful for a fall release.

Ray

[Bob Grimes]

Hi Ray, thanks for the update!

[Author]

Posts