| Time |
Nick |
Message |
| 01:16 |
|
mike_pizza joined #evergreen |
| 01:16 |
mike_pizza |
hi |
| 01:55 |
|
akilsdonk_ joined #evergreen |
| 02:13 |
|
nhilton joined #evergreen |
| 03:51 |
|
arthurdent joined #evergreen |
| 05:55 |
|
akilsdonk joined #evergreen |
| 06:03 |
|
wsmoak joined #evergreen |
| 06:03 |
|
wsmoak joined #evergreen |
| 07:48 |
|
collum joined #evergreen |
| 07:53 |
|
rjackson-isl joined #evergreen |
| 07:55 |
|
akilsdonk_ joined #evergreen |
| 07:59 |
|
sarabee joined #evergreen |
| 08:19 |
|
ericar joined #evergreen |
| 08:21 |
|
jboyer-isl joined #evergreen |
| 08:36 |
|
akilsdonk joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:43 |
|
mrpeters joined #evergreen |
| 09:28 |
|
yboston joined #evergreen |
| 10:05 |
|
loocorez_ joined #evergreen |
| 10:12 |
* mmorgan |
is trying to understand entries like this in the pg logs for catalog searches: |
| 10:12 |
mmorgan |
2014-12-02 11:28:57 db postgres[19609]: [93-1] 2014-12-02 11:28:57.262 EST [172.29.120.66(43932)] [19609]: [92-1] user=evergreen,db=evergreen,e=00000 LOG: duration: 81242.365 ms statement: SELECT* -- bib search: #CD_documentLength #CD_meanHarmonic #CD_uniqueWords #staff core_limit(10000) limit(1000) estimation_strategy(inclusion) keyword: #descending sort(pubdate) filter_group_entry(4) filter_group_entry(4) ko |
| 10:13 |
mmorgan |
Am I reading correctly that this search took 81 seconds? |
| 10:14 |
berick |
mmorgan: yes |
| 10:16 |
mmorgan |
Hmm. So this would likely time out on the user side, showing them no hits? |
| 10:17 |
berick |
yes |
| 10:17 |
berick |
it would time out around 60 seconds |
| 10:19 |
mrpeters |
morning all, I'm tinkering around with bug 1361266 and am wondering what i might be missing that adding a <input dojoType="dijit.form.DateTextBox" id="dob" name="date_of_birth" required="true" /> on eg/opac/register.tt2 doesn't actually provide the dojo date picker. I know register.tt2 includes base.tt2, which should include js.tt2 (which I think implements the dojo javascript) so I thought this might work. Obviously not a fix for the bug, but tryi |
| 10:19 |
pinesol_green |
Launchpad bug 1361266 in Evergreen "Patron self-registration form accepts date of birth in wrong format" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1361266 |
| 10:20 |
tsbere |
mrpeters: Is dojo being loaded? Because dojo only loads if "wanted" |
| 10:20 |
mrpeters |
tsbere: i think that is the question I am asking. How do I make it "wanted" for this particular template? |
| 10:21 |
mmorgan |
berick: I am also seeing some searches that took about 350 seconds, almost 6 minutes, which seems unreasonably long :-( |
| 10:22 |
tsbere |
mrpeters: Er.....add a [%- want_dojo = 1 %] somewhere? |
| 10:22 |
|
RoganH joined #evergreen |
| 10:23 |
tsbere |
mrpeters: want_dojo gets enabled in various circumstances, usually by header.tt2, but is used in a wrapper. As such, if the page sets it, the wrapper should see it. |
| 10:23 |
mmorgan |
SELECT * -- bib search: #CD_documentLength #CD_meanHarmonic #CD_uniqueWords core_limit(10000) limit(1000) estimation_strategy(inclusion) keyword: filter_group_entry(4) history site(MIDDLESEX) depth(1) is an example, not sure why this would take that long. |
| 10:24 |
mrpeters |
ok, i see some want_dojo = 1; stuff in header.tt2 |
| 10:25 |
tsbere |
fun, we say "we always want it", then say "if we have autosuggest turned on, or google books turned on, or novelist turned on, we want it" |
| 10:25 |
* tsbere |
thinks that "we always want it" should be moved to the advanced search page |
| 10:26 |
mrpeters |
wait, so if we always say we want it why wouldnt it be enabled on register.tt2? |
| 10:26 |
tsbere |
mrpeters: It is also possible you just don't have your syntax correct. I am not an expert. :P |
| 10:27 |
tsbere |
Or maybe we don't have *enough* of dojo in the tpac for the date picker. |
| 10:27 |
mrpeters |
so the staff client tt2 templates load a different amount of dojo? |
| 10:29 |
tsbere |
mrpeters: It may be that we don't have the full dijit code loaded as we aren't using most of that functionality in tpac right now |
| 10:30 |
mrpeters |
ok, i was trying not to introduce new javascript but maybe i just need to throw a popup if it doesnt meet the required format or something |
| 10:31 |
tsbere |
mrpeters: Specifically, have you added any javascript box that does a dojo.require('dijit.form.DateTextBox'); ? |
| 10:32 |
jeff |
using full paths to refer to things may help here. if you're talking about Open-ILS/src/templates/actor/user/register.tt2 i believe that is wrapped by Open-ILS/src/templates/base.tt2 (and not the OPAC base, etc) |
| 10:32 |
tsbere |
jeff: I believe he is talking the tpac self-reg form, which does use the OPAC base |
| 10:33 |
jeff |
but if you're talking about Open-ILS/src/templates/opac/register.tt2, that does use Open-ILS/src/templates/opac/parts/base.tt2 and friends. |
| 10:33 |
mrpeters |
jeff -- I am talking about the latter --- the /eg/opac/register page for self registration |
| 10:34 |
jeff |
hopefully that helps point you in a good direction as far as understanding why different dojo is present in "staff only" tt2 interfaces like the user editor vs opac interfaces |
| 10:34 |
mrpeters |
right now i've just added the want dojo, and then <input dojoType="dijit.form.DateTextBox" id="dob" name="date_of_birth" required="true" /> before the submit buttons |
| 10:34 |
mrpeters |
it does jeff, thank you |
| 10:37 |
mrpeters |
i imagine adding my own dateValidation.js to the TPAC would be frowned upon for core? |
| 10:37 |
mrpeters |
http://pastie.org/9758363 type of thign |
| 10:38 |
tsbere |
mrpeters: I would object to that specific code. If only due to lack of translation on the alert. :P |
| 10:38 |
mrpeters |
true |
| 10:38 |
tsbere |
mrpeters: For the date picker, you should try adding the dojo.require javascript statement somewhere. |
| 10:43 |
mrpeters |
ok, yeah, i see how that is happening for autosuggest now |
| 10:56 |
bshum |
I thought want_dojo was always required now |
| 10:56 |
bshum |
Or at least, I think we did that in 2.6 |
| 10:56 |
bshum |
And up |
| 10:57 |
|
vlewis joined #evergreen |
| 10:58 |
mrpeters |
i think ive got myself all kinds of confused now |
| 10:59 |
mrpeters |
I have an awesome button that does nothing and no field ha - https://eg-master.emeralddata.net/eg/opac/register |
| 11:00 |
|
akilsdonk joined #evergreen |
| 11:00 |
mrpeters |
im sure i need to define jsId=setDateOfBirth still though |
| 11:12 |
csharp |
mmorgan: are you able to run those queries directly on the DB? perhaps an EXPLAIN or EXPLAIN ANALYZE would provide clues |
| 11:13 |
bshum |
Probably have to capture more of the query string, if it's only getting the first 100 characters or whatnot |
| 11:13 |
csharp |
mmorgan: another possibility is the need for a VACUUM ANALYZE on your metabib. tables |
| 11:13 |
|
sarabee joined #evergreen |
| 11:14 |
csharp |
bshum: right |
| 11:14 |
bshum |
csharp++ # good ideas |
| 11:14 |
bshum |
:D |
| 11:15 |
mmorgan |
csharp: bshum: Yes, we're planning on examining those full queries. We did a vacuum analyze over Thanksgiving, and it shaved a few seconds off our searches, but didn't make them appreciably faster. |
| 11:15 |
csharp |
mmorgan: what version are you running? |
| 11:16 |
mmorgan |
2.6.2 |
| 11:16 |
* csharp |
is worried about search speed moving from 2.5 to 2.7.1 next month |
| 11:16 |
tsbere |
csharp/mmorgan: Grab everything after "bib search:" and dump it into query_parser.pl as the -query="blah" param to possibly get the full core query - That won't help with the wrapper function, though. |
| 11:16 |
bshum |
mmorgan: And what's in "filter_group_entry(4)" |
| 11:17 |
bshum |
"history" seems like a fairly broad search |
| 11:17 |
tsbere |
csharp/mmorgan: Oh, query_parser.pl would be in Open-ILS/src/support-scripts/test-scripts |
| 11:18 |
|
cokesme joined #evergreen |
| 11:18 |
bshum |
Oooh, fancy, tsbere++ |
| 11:18 |
mmorgan |
"filter_group_entry(4)" is a format filter "Books(All)" - we are suspicious that might be part of it |
| 11:19 |
|
cokesme left #evergreen |
| 11:19 |
mmorgan |
"history" IS a broad search, but, hey, it happens :) |
| 11:19 |
bshum |
mmorgan: Hey, fwiw, my metric for broad in our DB is doing searches for "Connecticut" or "Cat" and seeing how long it takes. |
| 11:19 |
mmorgan |
and it looks a little funny when the catalog says we don't have any books on "history" ;-) |
| 11:20 |
bshum |
What about behind the scenes, which version of PostgreSQL are you using? |
| 11:21 |
mmorgan |
looks like PostgreSQL 9.1.9 |
| 11:21 |
csharp |
tsbere++ |
| 11:22 |
|
dreuther_ joined #evergreen |
| 11:23 |
bshum |
mmorgan: Have you done anything with https://bugs.launchpad.net/evergreen/+bug/1374091 locally on your system? |
| 11:23 |
pinesol_green |
Launchpad bug 1374091 in Evergreen 2.7 "unapi.bre and slow views" (affected: 1, heat: 8) [Undecided,Fix released] |
| 11:24 |
bshum |
That was applied in 2.6.4-ish |
| 11:24 |
bshum |
But I know that bug was a huge stumbler for our performance when we moved up to 2.6 during the summer. |
| 11:24 |
bshum |
Along with tuning in our PG database, but that was the worst part. |
| 11:26 |
mmorgan |
bshum: I think we did, but will need to verify. |
| 11:28 |
bshum |
With the changes to formats in 2.6, I'd also be curious to know how your filter_group_entry pointed back |
| 11:28 |
bshum |
And maybe something isn't quite optimal there |
| 11:29 |
bshum |
We don't use that feature in our catalogs, so I've never tested it. |
| 11:31 |
bshum |
csharp: I'd say speed and performance considerations are always a critical element with every upgrade. :) |
| 11:32 |
* bshum |
generally loves the new icons and formats, but does think it has been an interesting road walked thus far. |
| 11:37 |
mmorgan |
So we have a few leads to follow now, thanks all! |
| 11:37 |
mmorgan |
berick++ csharp++ bshum++ tsbere++ |
| 11:38 |
* mmorgan |
needs to investigate system crankiness. |
| 11:39 |
|
mllewellyn joined #evergreen |
| 11:39 |
|
sandbergja joined #evergreen |
| 11:52 |
|
dreuther joined #evergreen |
| 12:01 |
|
sarabee joined #evergreen |
| 12:19 |
|
jihpringle joined #evergreen |
| 12:21 |
|
nhilton joined #evergreen |
| 12:23 |
|
nhilton_ joined #evergreen |
| 12:26 |
|
ericar joined #evergreen |
| 13:55 |
|
nhilton joined #evergreen |
| 14:00 |
|
collum joined #evergreen |
| 14:06 |
|
kmlussier joined #evergreen |
| 14:17 |
kmlussier |
Good afternoon #evergreen! |
| 14:18 |
* bshum |
waves over at kmlussier |
| 14:42 |
jeff |
afternoon! |
| 14:44 |
maryj |
Good afternoon! |
| 14:45 |
kmlussier |
@dessert [someone] |
| 14:45 |
* pinesol_green |
grabs some Apple Crisp for artunit |
| 14:45 |
kmlussier |
artunit is well deserving of an afternoon snack. |
| 14:49 |
|
buzzy joined #evergreen |
| 14:57 |
|
akilsdonk joined #evergreen |
| 15:06 |
|
nhilton joined #evergreen |
| 15:10 |
|
Dyrcona joined #evergreen |
| 15:10 |
|
dreuther_ joined #evergreen |
| 15:38 |
phasefx |
berick: is it always port 7682 that the web client will try to use for osrf-websocket-translator? |
| 15:40 |
berick |
phasefx: yes. |
| 15:40 |
berick |
yes, we never use the non-ssl port |
| 15:41 |
berick |
at least not in the browser client |
| 15:41 |
phasefx |
berick: gracias; that was my next question, whether it was using SSL or something :D |
| 15:41 |
berick |
yeah, 7680 is non-ssl, 7682 is ssl |
| 15:42 |
berick |
for the default opensrf websocket config |
| 15:43 |
phasefx |
berick: does it look enough like HTTP you think that I should try ListenHTTPS with pound? |
| 15:45 |
berick |
phasefx: probably worth a shot. i believe it looks (more or less) like a prolonged HTTPS request |
| 15:46 |
phasefx |
wikipedia says it gets interpreted as an Upgrade request, which I'm not familiar with. thanks man |
| 15:48 |
jeff |
with the disclaimer that i've not tried it, you might have better luck with a ListenHTTP directive. |
| 15:48 |
phasefx |
jeff: roger that |
| 15:50 |
phasefx |
bigger picture, what is actually listening on that port, apache or something else? I went through http://evergreen-ils.org/~erickson/browser-client-deps.html, but I think I'm missing something |
| 15:50 |
jcamins |
phasefx: I know nothing about pound, but I do know that setting up reverse proxies with websockets is kind of weird because you have to forward the connection upgrade request. |
| 15:51 |
bshum |
phasefx: I think apache-websockets is covered in the new OpenSRF master / 2.4 series |
| 15:51 |
phasefx |
jcamins: sounds scary enough that I'm going to stay away from it for a while; can just work through vpn |
| 15:51 |
jeff |
phasefx: having done a tiny about of further reading, i don't think you're likely to have pound work. depending on your needs, nginx will probably work better. |
| 15:51 |
bshum |
Whenever 2.4.0 for OpenSRF is cut, it should have that in the new steps |
| 15:51 |
phasefx |
bshum: gracias; I didn't check to see how old my opensrf is |
| 15:51 |
berick |
phasefx: apache listens on the port |
| 15:52 |
jcamins |
... uh-oh. |
| 15:52 |
berick |
then hands the request to a module. for apache, it's basically a long-running request |
| 15:52 |
* jcamins |
may have forgotten about this when he set up a reverse proxy last weekend. |
| 15:52 |
jcamins |
Ummm... oops. |
| 15:53 |
phasefx |
berick: there's nothing for that yet in the example config? |
| 15:54 |
|
nhilton_ joined #evergreen |
| 15:54 |
jcamins |
phasefx: it's probably good I saw you mentioning websockets and reverse proxies. |
| 15:54 |
jeff |
heh |
| 15:54 |
jcamins |
I guess I know what I'm doing tonight. |
| 15:54 |
phasefx |
:D |
| 15:55 |
berick |
phasefx: see opensrf master README |
| 15:55 |
phasefx |
berick: gracias |
| 15:56 |
* phasefx |
bumped the node.js version in the qa tests, incidentally |
| 15:57 |
|
akilsdonk_ joined #evergreen |
| 16:09 |
bshum |
tsbere++ # helping me read the closed_dates.js bits |
| 16:26 |
|
arthurdent left #evergreen |
| 16:27 |
|
mike_pizza left #evergreen |
| 16:35 |
phasefx |
so close.. :) WebSocket connection to blah failed: WebSocket opening handshake was canceled Uncaught Error: WebSocket Error [object Event] : undefined socket.onerror closing websocket |
| 16:36 |
* phasefx |
goes poking at opensrf_ws.js, see if he can get a better error |
| 16:43 |
berick |
phasefx: testing in chrome? |
| 16:43 |
phasefx |
berick: yes, chrome and chromium |
| 16:44 |
phasefx |
happens in firefox as well |
| 16:44 |
berick |
what happens if you go to https://hostname:7682 |
| 16:44 |
berick |
note: FF won't work with self-signed certs :( |
| 16:45 |
phasefx |
untrusted cert.. oy. I'm using the IP address to get around not wanting to fool with pound |
| 16:45 |
berick |
heh, just had a spider slowly drop down on its web between me and my screen |
| 16:46 |
berick |
in chrome, can you click through the cert problem? |
| 16:46 |
kmlussier |
berick: And you're still sitting at the computer and typing on your keyboard? |
| 16:46 |
* kmlussier |
would have run away screaming. :) |
| 16:46 |
phasefx |
berick: actually got it working in firefox, added an exception for the cert |
| 16:47 |
berick |
phasefx: oh, good. wonder why that didn't work for me before.. *shrug* |
| 16:47 |
berick |
kmlussier: i gently pusehd it aside with a stack of paper ;) |
| 16:47 |
berick |
sent it on its merry way |
| 16:48 |
phasefx |
berick: something strange though.. I tried https://foo/eg/staff/, and it gets a 404 in chrome and works in Firefox |
| 16:48 |
phasefx |
instead of http://foo/eg/staff/ |
| 16:49 |
* eeevil |
kills timezone offset problem for renew on webby for great justice |
| 16:49 |
phasefx |
well now that breaks too in chrome.. what did I do? *8) |
| 16:49 |
berick |
phasefx: what you always do ;) |
| 16:49 |
phasefx |
berick: trailing slash or lack thereof |
| 16:49 |
berick |
@who has chaos powers |
| 16:49 |
pinesol_green |
chatley has chaos powers. |
| 16:49 |
* phasefx |
even broke pinesol_green ;) |
| 16:50 |
phasefx |
berick: working in chrome for me now too |
| 16:50 |
berick |
awesome |
| 16:50 |
|
dreuther joined #evergreen |
| 16:51 |
phasefx |
berick: I think starting from the non-SSL login page was a contributing factor to breakage |
| 16:52 |
berick |
yeah, cuz then you get no chance to click through the warning |
| 16:57 |
eeevil |
berick: heads up! I'm pulling your fixes into collab/miker/web-client-sprint1-bug-fixing-rebased-collab, just to keep the bug fixes together |
| 16:57 |
berick |
eeevil++ |
| 16:58 |
|
akilsdonk_ joined #evergreen |
| 16:59 |
eeevil |
we can squash/reorder/etc later, I figure |
| 17:01 |
jeff |
togetherness! |
| 17:01 |
* jeff |
grins |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:15 |
|
mrpeters left #evergreen |
| 17:44 |
|
nhilton joined #evergreen |
| 21:02 |
|
sarabee joined #evergreen |
