| Time |
Nick |
Message |
| 00:10 |
|
jamesrf joined #evergreen |
| 01:10 |
|
StomproJ joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:55 |
|
StomproJosh joined #evergreen |
| 07:04 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
bos20k joined #evergreen |
| 07:29 |
|
bdljohn joined #evergreen |
| 08:08 |
|
littlet joined #evergreen |
| 08:45 |
|
aabbee joined #evergreen |
| 08:53 |
|
sandbergja joined #evergreen |
| 09:11 |
|
collum joined #evergreen |
| 09:12 |
|
jamesrf joined #evergreen |
| 09:29 |
|
Dyrcona joined #evergreen |
| 09:36 |
|
yboston joined #evergreen |
| 09:37 |
csharp |
JBoyer: Dyrcona: or others running websocketd in production - did you see an increase in demand for opensrf.settings drones? |
| 09:38 |
Dyrcona |
csharp: I'm not aware of an increase in settings drones. |
| 09:38 |
csharp |
or an overall increase in opensrf drones? |
| 09:38 |
csharp |
ok |
| 09:38 |
Dyrcona |
I did increase some drone counts: pcrud, etc. when we went to 3.0. |
| 09:39 |
Dyrcona |
The web staff client makes heavy use of pcrud. |
| 09:40 |
csharp |
yeah, we did that too |
| 09:43 |
Dyrcona |
I was looking for my notes on it, but can't find them. |
| 09:44 |
Dyrcona |
Out of curiosity, I'm going to see how many settings drones are running on our brick heads. |
| 09:46 |
csharp |
we had 15 and they where tapped out, so I upped them to 25 and now there's some headroom |
| 09:46 |
csharp |
honestly wasn't looking closely before the change, so possible it's not a new problem |
| 09:47 |
Dyrcona |
We're running 5/40 on each of our 5 brick heads for opensrf.settings. |
| 09:48 |
Dyrcona |
Not sure websocketd would be the culprit. Maybe you have more web staff client users than we do? We still have a number of sites using XUL. |
| 09:48 |
* Dyrcona |
wouldn't be surprised if a good % of our sites don't know that there is a web staff client. :) |
| 09:48 |
Dyrcona |
Y'know, the ones that never come to meetings.... |
| 09:50 |
|
jvwoolf joined #evergreen |
| 09:52 |
JBoyer |
I dont have good pre-websocketd data but our settings limits are min 20 max 120 and we hover around 20-35 most of the time. |
| 09:52 |
Dyrcona |
I recently squashed my config branch into a single commit, so I also lost the actual values for the change in opensrf.xml. |
| 09:52 |
Dyrcona |
Hmm... Why do you guys use so many more than us? |
| 09:54 |
JBoyer |
I have all of our services set to small, medium, or large counts in my template and I gave settings a large limit set. (it also specifies a min spare of 15, so that can keep things a little higher than strictly necessary) |
| 09:55 |
JBoyer |
The fact that it never seems to top 40 means I could (should?) probably revisit that. |
| 09:55 |
Dyrcona |
I can say that I didn't make any changes for switching from apache2-websocket to websocetd. The changes that I did make were because of 3.0 and the web staff client. |
| 09:56 |
JBoyer |
Same. How the client makes backend calls shouldn't have an effect on the number of calls it makes. |
| 09:56 |
Dyrcona |
I do believe I upped opensrf.settings and open-ils.auth* as well as pcrud and possibly 1 or 2 other, but I pretty much only upped the max. |
| 09:56 |
berick |
csharp: i wouldn't be too surprised if websocketd required more opensrf.settings drones. it spawns a new process for every connection |
| 09:57 |
berick |
unlike apache which reuses processes |
| 09:58 |
Dyrcona |
berick: Just to be pedantic, I think you mean new thread. |
| 09:58 |
berick |
i don't |
| 09:58 |
JBoyer |
Didn't realize that. |
| 10:00 |
berick |
it's very simple compared to apache, no child_init, no max_requests, etc. just fork -> connect osrf -> do work -> die |
| 10:00 |
Dyrcona |
berick: Funny. It's using threads (LWP) on my systems. |
| 10:01 |
Dyrcona |
I get two processes, and the second has a large number of threads. |
| 10:02 |
berick |
Dyrcona: websocketd? |
| 10:02 |
Dyrcona |
Yes. |
| 10:02 |
berick |
that's unexpected. the osrf C libs are not threadsafe |
| 10:02 |
Dyrcona |
pgrep -af websocketd shows two processes. |
| 10:03 |
Dyrcona |
ps -L $PPID shows 1 |
| 10:03 |
Dyrcona |
ps -L $CHILD_PID shows 19 on one of my brickheads. |
| 10:04 |
Dyrcona |
What kernel are you running? |
| 10:04 |
Dyrcona |
Thread safe or not, it seems to be working. |
| 10:04 |
berick |
4.15.0-45-generic |
| 10:05 |
berick |
ps ax shows a process per connection here |
| 10:05 |
berick |
Dyrcona: pgrep -af websocket |
| 10:05 |
berick |
the child processes don't have websocketd in the name |
| 10:05 |
berick |
just the path to the binary |
| 10:06 |
berick |
the parent websocketd process probably is threaded, but it just manages the connections |
| 10:06 |
berick |
and the forking |
| 10:07 |
Dyrcona |
That must be it. I've seen programs do that before, start a thread and then fork inside the thread. |
| 10:07 |
* Dyrcona |
thinks its dumb. |
| 10:08 |
Dyrcona |
Either use threads or fork, don't make things more complicated by doing both. |
| 10:09 |
Dyrcona |
http://www.itnumeric.com/wp-content/uploads/2011/11/John-McCarthy.jpg |
| 10:15 |
Dyrcona |
I suppose if you're running an external program, you have to fork() and exec(), but why manage that with threads? I suppose websocketd's case isn't as bad as another I've seen where the whole point was to run random programs from a list... In that case, the use of threads was wholly unjustified. |
| 10:15 |
* Dyrcona |
steps down from soapbox. ;) |
| 10:17 |
* berick |
just learned about chrome://restart |
| 10:17 |
Dyrcona |
Either way, it doesn't seem to be using that man opensrf.settings drones for us. |
| 10:17 |
berick |
kill all the chrome procs (not just browser) |
| 10:18 |
Dyrcona |
Yeah... It's supposed to prompt you for that after an update while it's running, but I haven't seen it do that lately. |
| 10:18 |
Dyrcona |
IOW, it's what the "Resart" button does when/if it shows up. |
| 10:19 |
Dyrcona |
At least, I *think* that's what it does. I could be wrong. I frequently am. :) |
| 10:21 |
Dyrcona |
csharp: What version of OpenSRF are you running? I've got 3.0 with the websocket-stdio patch backported. |
| 10:22 |
* Dyrcona |
double checks that. |
| 10:23 |
Dyrcona |
Yeahp. |
| 10:32 |
|
bos20k_ joined #evergreen |
| 10:41 |
csharp |
Dyrcona: just installed 3.1.0 last night and set up websocketd on top of that |
| 10:41 |
* Dyrcona |
wonders if it's because of a change from 3.0.1 to 3.1.0? |
| 10:42 |
csharp |
berick: that's good to know re: settings drones vs. apache-websockets |
| 10:43 |
|
Christineb joined #evergreen |
| 10:45 |
|
bos20k joined #evergreen |
| 10:45 |
csharp |
despite that increase, our servers are happier on websocketd |
| 10:46 |
csharp |
and we're hearing reports of snappier web client performance |
| 10:46 |
csharp |
@decide happier or snappier? |
| 10:46 |
pinesol |
csharp: That's a tough one... |
| 10:46 |
Dyrcona |
websocketd++ |
| 10:47 |
csharp |
websocketd++ |
| 10:47 |
Dyrcona |
I'm not seeing what berick says might happen. I have 19 websockets going and only 5 settings drones. |
| 10:47 |
Dyrcona |
Unless, I'm also running settings on the drone servers by mistake? |
| 10:47 |
berick |
Dyrcona: it only talks to the settings drone at fork time to get the settings. it's not a persistent connection. |
| 10:48 |
Dyrcona |
Well, OK, then. |
| 10:48 |
* Dyrcona |
goes back to messing with hosts files so he can tunnel to his training database. |
| 10:50 |
miker |
Dyrcona: a significant benefit to using threads to manage the i/o for the forked opensrf handler is much-reduced memory overhead. even linux's clone-based processes are a bit heavier than threads due to copy-on-write. exactly one copy of the go interpreter in mem is good (the websocketd binary is like 7MB, and we have servers with 500+ concurrent websocket connections) |
| 10:52 |
Dyrcona |
OK, fine. I'm generally more concerned with programmer overhead not program overhead. |
| 10:57 |
|
khuckins joined #evergreen |
| 11:11 |
|
sandbergja joined #evergreen |
| 11:11 |
* Dyrcona |
mumbles something about coroutines.... ;) |
| 11:11 |
Dyrcona |
Anyway, I'm sure you're all thrilled that I can now tunnel to my training database through any of my tunnel endpoints. |
| 11:12 |
Dyrcona |
I apparently used the wrong file as the model when adding a new server to the hosts files yesterday. |
| 11:23 |
|
bos20k joined #evergreen |
| 11:37 |
|
yar joined #evergreen |
| 11:44 |
|
jamesrf joined #evergreen |
| 11:49 |
|
bos20k joined #evergreen |
| 12:25 |
|
stephengwills joined #evergreen |
| 12:32 |
|
Dyrcona joined #evergreen |
| 12:44 |
Dyrcona |
Heh. So, go looking into fixing a "bug," and turns out not to be a bug, just an unfortunate consequence of using regular expressions. |
| 12:48 |
|
jvwoolf left #evergreen |
| 12:48 |
|
jihpringle joined #evergreen |
| 13:07 |
|
stephengwills joined #evergreen |
| 13:16 |
|
stephengwills joined #evergreen |
| 13:24 |
|
sandbergja_ joined #evergreen |
| 13:30 |
|
stephengwills joined #evergreen |
| 13:36 |
|
mmorgan joined #evergreen |
| 13:53 |
csharp |
@blame bug 1751800 |
| 13:53 |
pinesol |
csharp: It's all bug 1751800's fault! |
| 13:53 |
csharp |
bug 1751800 |
| 13:53 |
pinesol |
Launchpad bug 1751800 in Evergreen "web client: reports - column labels spontaneously re-sort when deleting template fields" [Medium,Confirmed] https://launchpad.net/bugs/1751800 |
| 13:58 |
|
beanjammin joined #evergreen |
| 14:06 |
|
jvwoolf joined #evergreen |
| 14:09 |
|
stephengwills joined #evergreen |
| 14:41 |
|
jvwoolf joined #evergreen |
| 14:51 |
|
HPL joined #evergreen |
| 15:00 |
|
jvwoolf1 joined #evergreen |
| 15:17 |
Dyrcona |
III-- |
| 15:19 |
Dyrcona |
@blame NDA |
| 15:19 |
pinesol |
Dyrcona: NDA broke Evergreen. |
| 15:21 |
jeff |
Nope. Not going to let *that* happen. :-) |
| 15:46 |
|
sandbergja_ joined #evergreen |
| 15:50 |
pinesol |
[evergreen|Dan Wells] First pass at 3.3 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ed9eeac> |
| 16:04 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.1.10 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1d5c79e> |
| 16:04 |
pinesol |
[evergreen|Dan Wells] Forward-port 3.2.4 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f30b746> |
| 16:14 |
pinesol |
[evergreen|Dan Wells] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67ed733> |
| 16:15 |
|
csharp joined #evergreen |
| 16:16 |
Dyrcona |
dbwells++ |
| 16:16 |
|
Guest15924 joined #evergreen |
| 16:24 |
pinesol |
[evergreen|Dan Wells] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dc6b9d9> |
| 16:34 |
mmorgan |
Hmm. I'm not seeing web client logins recorded in actor.usr_activity. Am I missing something? |
| 16:55 |
jeff |
A row in config.usr_activity_type, I suspect. |
| 16:55 |
jeff |
I don't know that there's an upgrade script that adds one. |
| 16:57 |
berick |
hmm, yeah, there's no websocket "ehow" in config.usr_activity_type |
| 16:57 |
jeff |
It would need to be ws-translator-v2, yes? |
| 16:57 |
berick |
thought it would default to generic "login", but all of them define an "ehow" type, there's not fully default "login" even tytpe |
| 16:57 |
jeff |
Yeah. It looks like the functions are set to permit generic entries. Might be good to add both. |
| 16:58 |
berick |
ws-translator-v1 and ws-translator-v2 are needed |
| 16:58 |
berick |
and, yeah, a login version with no 'ehow' value |
| 16:58 |
berick |
ditto verify |
| 17:00 |
berick |
mmorgan: I'll open a bug |
| 17:00 |
mmorgan |
berick++ |
| 17:00 |
jeff |
mmorgan++ berick++ |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:02 |
|
yboston joined #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:21 |
|
khuckins joined #evergreen |
| 17:58 |
pinesol |
[evergreen|Dan Wells] Stop asciidoc from squawking about missing list number - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=81d5551> |
| 18:05 |
dbwells |
For any eager to help, the first beta of 3.3 is available in the "previews" area of the site (not the normal downloads area yet): https://evergreen-ils.org/downloads/previews/Evergreen-ILS-3.3-beta1.tar.gz |
| 18:06 |
dbwells |
We'll do a test install locally tomorrow, but it would be nice if someone else could do the same, and even better, run the upgrade script on a real 3.2.4 DB. |
| 18:07 |
dbwells |
The upgrade script is actually rather short this release, which overall is a good thing. |
| 18:18 |
berick |
dbwells++ |
| 18:27 |
|
sandbergja_ joined #evergreen |
| 18:40 |
|
sandbergja_ joined #evergreen |
| 21:33 |
|
sandbergja joined #evergreen |
| 21:58 |
|
beanjammin joined #evergreen |
