> > I just updated ELOG using the latest elogd.c, and now my Quick Filters seem 
> > to stop working after the first or second filter attempt.
> 
> Can you try if you can reproduce the problem with the current version? I tried
> your settings and could not reproduce it. I remember that I fixed some problems
> with quick filters, but that was some time ago (Apr 04). If the problem
> persists, can you send me your exact elogd.cfg?

Recai Oktas replied to me and let me know that I needed to use dpkg to create the 
new Debian package instead of manually compiling it. I reverted to the original 
Debian package to get everything running normally again, but I haven't had a 
chance to try the upgrade again. As soon as I went back to the original elogd 
everything worked fine (no changes to the elog.cfg required). I'm assuming that 
the problem came from attempting to recompile a Debian package install manually. 
Sorry for the bug scare!

Todd

> > I get the following in my THREADED logbook view:
> > 
> > "Adding new services, planned for 1090519200. Last revised: Thu Jul 15
> > 18:03:52 2004"
> 
> That should be fixed by the current version. Please update.

Thanks!

> > With the "Preset text = " specified, when re-editing a logbook entry (say to
> > correct a spelling error) the text of the "Message" is replicated and placed
> > directly below the original text.
> 
> That should be fixed since revision 1.370 from Jul 7th, 2004. Please update.

Thanks!

> > I noticed that the gcc compiler options in the tarball Makefile were not
> > conducive to speed.  There, I tried changing the gcc options to:
> > 
> > CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall
> 
> Thank your for this hint, I changed my Makefile for the production code. However, I
> could not feel any difference between the two options. The real problem is the
> function getcfg(), which gets called many thousand times internally and has to parse
> elogd.cfg each time. Once I implement a hash table for that function, elogd should
> become faster by at least a factor of two.

Yeah - What's up with that?

I have seen this discussed before - Seems like it should be a priority to get this
fixed, as doing a hash table is straightforward, and the speed increase should be pretty
health - there are several c libraries available - check out "man 3 hsearch" for the
POSIX hash table management that already available.  Other c library searches that you
could use include bsearch (binary tree), tsearch (tree searching), btree (b+ tree). 
However, the easiest and most obvious one to use for elog appears to be a simple hash
table search (hsearch).

Is there something else  which is making this difficult to do?

> Is there something else  which is making this difficult to do?

Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
source code from the GNU C libarary or so. Since the last discussion I had lots of other
topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
and more up on the priority list.

> Ok, I added the option
> 
> Tooltip <attribute> = ...
> 
> I apply the HTML "title" tag to the whole table row, so the tooltip appears on the
> whole line, not only the attribute name. I guess this is much more intuitive. Give
> it a try. New version under CVS and available as a snapshot.

I like the implementation, especially with the tooltip popping up anywhere in the
area.  Thanks.

> > Is there something else  which is making this difficult to do?
> 
> Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
> source code from the GNU C libarary or so. Since the last discussion I had lots of other
> topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
> and more up on the priority list.

Speaking of windows I'd like to note that when I moved my call tracking config from a slow BSD
system (PPro 200Mhz) to a faster windows system (P3 733M) I noted a huge slow down in the
interface.  Talking about perhaps 1-2 seconds before to 10-15 seconds after.  Using
sysinternals file monitor I see that elogd is hammering each log file in the directory.  Not
sure what else is going on.  309 log files - only 1.25Meg.  

Anything I can do short of pruning down the files?

[Edit:  In both cases above my default view is filtered and sorted - so that I only see things
with a specific status.  Taking away the filtering resolves this hit - but does not explain the
speed difference between platforms.]

-D

Hi,

I have an ELOG installation on a RedHat linux server, called myserver. I 
can connect to this server with the following entries in the elogd.cfg file:
   [global]
   URL=http://myserver:8080
This works fine. I can log in, select logbooks, edit/create entries etc. 
etc.

However, I want this connection to be encrypted. So I activate stunnel (v4) 
in such a way that stunnel listens to port 8081 and forwards to the 
("remote") port 8080, which is the "original" elog port. I change the URL= 
entry in de elogd.cfg file to URL=https://myserver:8081 in order to use the 
SSL encrypted connection.

At this time, when I connect to https://myserver:8081 I get the 
welcome/login screen, but when I enter the (correct) username and password, 
the elog program does not show the contents of the logbook buts shows the 
loginscreen again. If I enter a wrong username/password, I do get a correct 
error-screen. So it seems that the connection is correct, but there is some 
sort of problem in ELOG. Anyone who can give me a hand here?