ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67734
|
Mon Jan 5 10:59:28 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 2.9 | Re: How to upgrade elog? | No. Just install the new version over the old one.
Banata wrote: |
any specified task to upgrade elog?
I have elog deployed in windows and linux centos.
please help me.
|
|
67735
|
Tue Jan 6 02:19:04 2015 |
| Banata | jogjacard@yahoo.com | Question | Linux | Windows | 2.9 | Re: How to upgrade elog? | thanx, so in linux I just need to install over the old ones?
I thought there are additional step on linux, hehehe thanx for the help sir
Stefan Ritt wrote: |
No. Just install the new version over the old one.
Banata wrote: |
any specified task to upgrade elog?
I have elog deployed in windows and linux centos.
please help me.
|
|
|
67837
|
Wed Mar 25 10:36:15 2015 |
| Tim Schel | tim.schelfhout@fixbrussel.be | Info | Linux | Windows | 3.00 | test | zezerze |
68078
|
Wed Aug 12 16:59:30 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Isolating search urls | 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 |
68079
|
Wed Aug 12 17:19:45 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | 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
|
|
Draft
|
Thu Aug 13 10:05:22 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | Thanks for the quick response!
The idea is to run multiple instances of elog where
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
|
|
|
68083
|
Thu Aug 13 10:06:23 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | 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
|
|
|
68088
|
Mon Aug 17 10:32:51 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls | 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
|
|
|
|
|