Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 66 of 238  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
icon5.gif   Preset on duplicate, posted by Daniel Sajdyk on Mon Aug 31 22:35:03 2015 

Hi.

Is there any way that "Preset on duplicate" contain ID entry from which it was duplicated?

 

Cheers

Daniel.

icon5.gif   Draft saved is treated as an entry edit, posted by Daniel Sajdyk on Fri Aug 28 21:01:42 2015 entry.png

Hello.

In Elog i have attribute called "Zmieniano" (eng. changed)  which should store how many times entry was edited. If entry was not edited it should have only preset value "oryginalny wpis" (eng. oryginal entry), but when I edit it, it should have also date, time, and person who make edit (this is made by "Subst on Edit Zmieniano = $Zmieniano<br>- Zmiana $date przez $long_name z $remote_host)". 

From version V3.1.1-3f311c5 I have problem with that. 

When I add entry, and entry is auto saved, then auto save is shown in the attribute "Zmieniano" (eng. changed) as an next edit, which I dont want. Entry from attached screenshot was not edited, but in "Zmieniano" (eng. changed) attributes it has two values:

  • Oryginalny wpis (eng. oryginal entry),
  • Zmiana 27.08.2015, 10:52 przez Daniel Sajdyk z serwerownia.sr.lez (eng. Changed 27.08.2015.... ) 

The second value is autosave time. 

Is this a bug?

 

Regards

Daniel. 

 

    icon2.gif   Re: Draft saved is treated as an entry edit, posted by Andreas Luedeke on Mon Aug 31 09:38:38 2015 

Hi Daniel,

this is an undesired side effect of a new feature. I wouldn't call it a bug ;-)

There is no straight forward way for elog to distinguish between a "Submit" and an automatic save. Therefore the "... on edit = ..." kicks in when an entry is saved automatically.

I guess Stefan can figure out a workaround, but for the moment I would sugest that you just switch off the auto save feature -- if you want to keep your save history:

Save drafts = 0

Cheers
Andreas
 
Daniel Sajdyk wrote:Save drafts = 0

Hello.

In Elog i have attribute called "Zmieniano" (eng. changed)  which should store how many times entry was edited. If entry was not edited it should have only preset value "oryginalny wpis" (eng. oryginal entry), but when I edit it, it should have also date, time, and person who make edit (this is made by "Subst on Edit Zmieniano = $Zmieniano<br>- Zmiana $date przez $long_name z $remote_host)". 

From version V3.1.1-3f311c5 I have problem with that. 

When I add entry, and entry is auto saved, then auto save is shown in the attribute "Zmieniano" (eng. changed) as an next edit, which I dont want. Entry from attached screenshot was not edited, but in "Zmieniano" (eng. changed) attributes it has two values:

  • Oryginalny wpis (eng. oryginal entry),
  • Zmiana 27.08.2015, 10:52 przez Daniel Sajdyk z serwerownia.sr.lez (eng. Changed 27.08.2015.... ) 

The second value is autosave time. 

Is this a bug?

 

Regards

Daniel. 

 

 

       icon2.gif   Re: Draft saved is treated as an entry edit, posted by Daniel Sajdyk on Mon Aug 31 13:12:09 2015 

Hi Andreas and thank you very much for explanation ;)

So, we'll have to wait for new version which will correct this.

 

Cheers

Daniel.

Andreas Luedeke wrote:

Hi Daniel,

this is an undesired side effect of a new feature. I wouldn't call it a bug ;-)

There is no straight forward way for elog to distinguish between a "Submit" and an automatic save. Therefore the "... on edit = ..." kicks in when an entry is saved automatically.

I guess Stefan can figure out a workaround, but for the moment I would sugest that you just switch off the auto save feature -- if you want to keep your save history:

Save drafts = 0

Cheers
Andreas
 
Daniel Sajdyk wrote:Save drafts = 0

Hello.

In Elog i have attribute called "Zmieniano" (eng. changed)  which should store how many times entry was edited. If entry was not edited it should have only preset value "oryginalny wpis" (eng. oryginal entry), but when I edit it, it should have also date, time, and person who make edit (this is made by "Subst on Edit Zmieniano = $Zmieniano<br>- Zmiana $date przez $long_name z $remote_host)". 

From version V3.1.1-3f311c5 I have problem with that. 

When I add entry, and entry is auto saved, then auto save is shown in the attribute "Zmieniano" (eng. changed) as an next edit, which I dont want. Entry from attached screenshot was not edited, but in "Zmieniano" (eng. changed) attributes it has two values:

  • Oryginalny wpis (eng. oryginal entry),
  • Zmiana 27.08.2015, 10:52 przez Daniel Sajdyk z serwerownia.sr.lez (eng. Changed 27.08.2015.... ) 

The second value is autosave time. 

Is this a bug?

 

Regards

Daniel. 

 

 

 

icon5.gif   Send e-mail based on a hierarchy of attributes?, posted by Phil Rubin on Mon Aug 24 20:40:14 2015 

Is there a way to distribute e-mail based on the consideration of several attributes and values?  A simple example:  attributes type and category have several different values, say, routine and problem for type and hardware and software for category, but one would only like messages sent when there's a problem to different sets of hardware or software types.  Thus:

Email

type routine   category hardware = no message

                        category software = no message

type problem  category hardware =  a@bcd.efg, h@ijk.lmn

                         category software = 1@opq.rst, 2@uvw.xyz

    icon3.gif   Re: Send e-mail based on a hierarchy of attributes?, posted by Andreas Luedeke on Wed Aug 26 09:18:17 2015 

Yes, this can be done. See below for an example configuration.

Attributes = entrytype, category
Options entrytype = routine{1}, problem{2}
Options category = software, hardware

{1} Email category software =
{1} Email category hardware =
{2} Email category software =
1@opq.rst, 2@uvw.xyz
{2} Email category hardware = a@bcd.efg, h@ijk.lmn

Phil Rubin wrote:

Is there a way to distribute e-mail based on the consideration of several attributes and values?  A simple example:  attributes type and category have several different values, say, routine and problem for type and hardware and software for category, but one would only like messages sent when there's a problem to different sets of hardware or software types.  Thus:

Email

type routine   category hardware = no message

                        category software = no message

type problem  category hardware = a@bcd.efg, h@ijk.lmn

                         category software = 1@opq.rst, 2@uvw.xyz

 

icon1.gif   Version 3.1.1 of elog has been released, posted by Stefan Ritt on Tue Aug 4 15:35:39 2015 

Version 3.1.1, released August 4th, 2015

  • Updated CKEditor to version 4.5.1

  • Implemented "Date/Time format <attribute> = ..."

  • Implemented "Use Email Subject Edit = ..."

  • Replaced "Back" by "Delete" button

  • Fixed many issues with Draft Messages

  • CSS file is now in *addition* to the default file elog.css

  • Added LDAP documentation

  • Added "Logout to URL = ..." option

  • Added description of Apacher server authentication

    icon2.gif   Re: Version 3.1.1 of elog has been released, posted by Edmund Hertle on Thu Aug 20 14:23:43 2015 

There seems to be a small problem with the new "Date/Time format <attribute>" implementation. It works great for the detailed view of a single entry:

But fails to work on the list view (same entry, the Date column is formated as it should):

Relevant config part:

Time format Time Start = %H:%M:%S
Time format Time End = %H:%M:%S

Stefan Ritt wrote:

Version 3.1.1, released August 4th, 2015

  • Updated CKEditor to version 4.5.1

  • Implemented "Date/Time format <attribute> = ..."

  • Implemented "Use Email Subject Edit = ..."

  • Replaced "Back" by "Delete" button

  • Fixed many issues with Draft Messages

  • CSS file is now in *addition* to the default file elog.css

  • Added LDAP documentation

  • Added "Logout to URL = ..." option

  • Added description of Apacher server authentication

 

       icon2.gif   Re: Version 3.1.1 of elog has been released, posted by Stefan Ritt on Thu Aug 20 15:52:26 2015 

Thanks for reportung that bug. I fixed it in revision f828049.

Edmund Hertle wrote:

There seems to be a small problem with the new "Date/Time format <attribute>" implementation. It works great for the detailed view of a single entry:

But fails to work on the list view (same entry, the Date column is formated as it should):

Relevant config part:

Time format Time Start = %H:%M:%S
Time format Time End = %H:%M:%S

 

icon5.gif   Compiling for Windows, posted by Richard Stamper on Wed Aug 19 17:08:56 2015 

I am interested in using LDAP authentication for elogd on Windows for which it looks like I need to compile from source, enabling LDAP in the make file.

Does anyone have advice on build environments for Windows in which they have had success making elog?  Free ones preferably, such as Cygwin. 

icon5.gif   "Resolve host names" does not resolve host names, posted by Daniel Sajdyk on Wed Jul 1 11:05:32 2015 

Hello

I use Resolve host names = 1 in my config file, but I still get IP instead domain name.

I use elog in internal network with my own DNS.

Any sugesstions ?

Regards

Daniel. 

    icon2.gif   Re: "Resolve host names" does not resolve host names, posted by Stefan Ritt on Tue Aug 4 13:33:14 2015 

In elog I simplu use the function gethostbyaddr() to resolve the host name. If this does not work, the underlying OS does not know the hostname either. Probably you can test this with "nslookup a.b.c.d", to see any further error message.

Daniel Sajdyk wrote:

Hello

I use Resolve host names = 1 in my config file, but I still get IP instead domain name.

I use elog in internal network with my own DNS.

Any sugesstions ?

Regards

Daniel. 

 

       icon2.gif   Re: "Resolve host names" does not resolve host names, posted by Daniel Sajdyk on Tue Aug 18 14:23:29 2015 

I'm sorry... it was my mistake. I put Resolve host names in logbook config instead global.

Regards Daniel.

Stefan Ritt wrote:

In elog I simplu use the function gethostbyaddr() to resolve the host name. If this does not work, the underlying OS does not know the hostname either. Probably you can test this with "nslookup a.b.c.d", to see any further error message.

Daniel Sajdyk wrote:

Hello

I use Resolve host names = 1 in my config file, but I still get IP instead domain name.

I use elog in internal network with my own DNS.

Any sugesstions ?

Regards

Daniel. 

 

 

icon5.gif   IE 11 - Text Edit Toolbar Not Working, posted by John Krautkramer on Sat Aug 15 00:00:36 2015 

Hi,

I've been exploring elog. I find when using IE 11, the text editor formatting buttons don't work with HTML encoding selected. The entire toolbar is grayed out. It appears to work fine with Chrome. Any ideas or direction to look? elog v3.1.1 is running on RedHat EL5. I've tried the rpm installation, and source code compilation and installation with no change.

Any input would be greatly apriciated!

John

    icon2.gif   Re: IE 11 - Text Edit Toolbar Not Working, posted by Andreas Luedeke on Mon Aug 17 09:27:45 2015 

This reply has been written with IE 11 using the embedded HTML editor of ELOG. Therefore it is obviously not a problem of ELOG 3.1.1 with IE 11.

It could be a problem with your ELOG installation or it could be a problem with you IE 11 configuration. Can you use the HTML editor of this forum with IE11? Did you install ELOG 3.1.1 on top of an existing ELOG installation?

There was a recent post in the forum about IE11 and the HTML editor in the Forum. Did you read it?

Cheers, Andreas

John Krautkramer wrote:

Hi,

I've been exploring elog. I find when using IE 11, the text editor formatting buttons don't work with HTML encoding selected. The entire toolbar is grayed out. It appears to work fine with Chrome. Any ideas or direction to look? elog v3.1.1 is running on RedHat EL5. I've tried the rpm installation, and source code compilation and installation with no change.

Any input would be greatly apriciated!

John

 

       icon2.gif   Re: IE 11 - Text Edit Toolbar Not Working, posted by Stefan Ritt on Mon Aug 17 09:55:16 2015 

Also make sure you don't have "Compatibility Mode" turned on in IE11.

See here for example: http://winaero.com/blog/how-to-enable-compatibility-view-in-internet-explorer-11-ie11/

Andreas Luedeke wrote:

This reply has been written with IE 11 using the embedded HTML editor of ELOG. Therefore it is obviously not a problem of ELOG 3.1.1 with IE 11.

It could be a problem with your ELOG installation or it could be a problem with you IE 11 configuration. Can you use the HTML editor of this forum with IE11? Did you install ELOG 3.1.1 on top of an existing ELOG installation?

There was a recent post in the forum about IE11 and the HTML editor in the Forum. Did you read it?

Cheers, Andreas

John Krautkramer wrote:

Hi,

I've been exploring elog. I find when using IE 11, the text editor formatting buttons don't work with HTML encoding selected. The entire toolbar is grayed out. It appears to work fine with Chrome. Any ideas or direction to look? elog v3.1.1 is running on RedHat EL5. I've tried the rpm installation, and source code compilation and installation with no change.

Any input would be greatly apriciated!

John

 

 

          icon2.gif   Re: IE 11 - Text Edit Toolbar Not Working, posted by John Krautkramer on Mon Aug 17 16:30:17 2015 

The issue was IE Compatibility Mode. There were no websites in the list, but the "Display intranet sites in Compatibility View" was checked. Removing this fixed it.

Thanks for the help!

John

Stefan Ritt wrote:

Also make sure you don't have "Compatibility Mode" turned on in IE11.

See here for example: http://winaero.com/blog/how-to-enable-compatibility-view-in-internet-explorer-11-ie11/

Andreas Luedeke wrote:

This reply has been written with IE 11 using the embedded HTML editor of ELOG. Therefore it is obviously not a problem of ELOG 3.1.1 with IE 11.

It could be a problem with your ELOG installation or it could be a problem with you IE 11 configuration. Can you use the HTML editor of this forum with IE11? Did you install ELOG 3.1.1 on top of an existing ELOG installation?

There was a recent post in the forum about IE11 and the HTML editor in the Forum. Did you read it?

Cheers, Andreas

John Krautkramer wrote:

Hi,

I've been exploring elog. I find when using IE 11, the text editor formatting buttons don't work with HTML encoding selected. The entire toolbar is grayed out. It appears to work fine with Chrome. Any ideas or direction to look? elog v3.1.1 is running on RedHat EL5. I've tried the rpm installation, and source code compilation and installation with no change.

Any input would be greatly apriciated!

John

 

 

 

icon5.gif   Isolating search urls, posted by Philip Leung on Wed Aug 12 16:59:30 2015 

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

    icon2.gif   Re: Isolating search urls, posted by Stefan Ritt on Wed Aug 12 17:19:45 2015 

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

       icon2.gif   Re: Isolating search urls, posted by Philip Leung on Thu Aug 13 10:06:23 2015 

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

          icon2.gif   Re: Isolating search urls, posted by Philip Leung on Mon Aug 17 10:32:51 2015 

Is there no good way of differentiating search operations from others by URL?

Philip Leung wrote:

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

 

             icon2.gif   Re: Isolating search urls, posted by Stefan Ritt on Mon Aug 17 10:41:22 2015 

Look for "&subtext=" in the URL

Philip Leung wrote:

Is there no good way of differentiating search operations from others by URL?

Philip Leung wrote:

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

 

 

                icon2.gif   Re: Isolating search urls, posted by Philip Leung on Mon Aug 17 11:17:37 2015 

This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter

Stefan Ritt wrote:

Look for "&subtext=" in the URL

Philip Leung wrote:

Is there no good way of differentiating search operations from others by URL?

Philip Leung wrote:

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

 

 

 

                   icon2.gif   Re: Isolating search urls, posted by Stefan Ritt on Mon Aug 17 11:26:22 2015 

For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.

Philip Leung wrote:

This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter

Stefan Ritt wrote:

Look for "&subtext=" in the URL

Philip Leung wrote:

Is there no good way of differentiating search operations from others by URL?

Philip Leung wrote:

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

 

 

 

 

                      icon2.gif   Re: Isolating search urls, posted by Philip Leung on Mon Aug 17 11:28:08 2015 

Would there be a simple way to redirect all URLs BUT the ones which trigger searches?

Stefan Ritt wrote:

For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.

Philip Leung wrote:

This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter

Stefan Ritt wrote:

Look for "&subtext=" in the URL

Philip Leung wrote:

Is there no good way of differentiating search operations from others by URL?

Philip Leung wrote:

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

 

 

 

 

 

                         icon2.gif   Re: Isolating search urls, posted by Stefan Ritt on Mon Aug 17 11:36:49 2015 

No, no and again: no.

Philip Leung wrote:

Would there be a simple way to redirect all URLs BUT the ones which trigger searches?

Stefan Ritt wrote:

For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.

Philip Leung wrote:

This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter

Stefan Ritt wrote:

Look for "&subtext=" in the URL

Philip Leung wrote:

Is there no good way of differentiating search operations from others by URL?

Philip Leung wrote:

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

 

 

 

 

 

 

                            icon2.gif   Re: Isolating search urls, posted by Philip Leung on Mon Aug 17 11:52:54 2015 

Noted. Thank you for your time

Stefan Ritt wrote:

No, no and again: no.

Philip Leung wrote:

Would there be a simple way to redirect all URLs BUT the ones which trigger searches?

Stefan Ritt wrote:

For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.

Philip Leung wrote:

This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter

Stefan Ritt wrote:

Look for "&subtext=" in the URL

Philip Leung wrote:

Is there no good way of differentiating search operations from others by URL?

Philip Leung wrote:

Thanks for the quick response!

It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.

The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.

 

Stefan Ritt wrote:

I guess the underlying problem is the long time these requests take and block other users.

I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.

Philip Leung wrote:

Hello all,

I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.

Does anybody have any suggestions?

Regards,

Philip

 

 

 

 

 

 

 

 

 

ELOG V3.1.5-3fb85fa6