~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest13871
Irc2PGuest2974
Liorar_
Nausicaa_
Onn4l7h
StormyCloudInc
admin
anon
anontor
anu
cheddah
itsjustme_
j6
limak
not_bob_afk
poriori_
qend-irc2p_
u5657
dr|z3d
zzz: here's a thing to maybe look at, re jetty. the temp folder that's created on startup to accomodate extracting war files. over time they mount up.. can we either re-use a fixed name for the temp dir, or clearup stale dirs on startup?
zzz
you mean they're sticking around across restarts?
zzz
*JVM restarts?
dr|z3d
yeah
dr|z3d
I've just cleared probably 100+ of them in /tmp/
dr|z3d
they don't contain much, if anything, but they probably don't need to be there. I'd suggest setting /tmp/i2p_workdir or something and just using that, empyting anything that happens to be there on restart.
zzz
for me, the jetty dirs are inside the /tmp/i2p-xxx.tmp dir, which gets deleted at router shutdown, which is the design intent
zzz
so either there's something different about your setup, or you changed something
dr|z3d
could be that, maybe I'm not waiting long enough.
zzz
not a 'long enough' issue, if they're not inside the i2p context temp dir, something is wrong
dr|z3d
location isn't the issue, they're fine, i2p_xxx.tmp or whatever.
zzz
but the whole i2p-xxx.tmp dir gets deleted at shutdown. I don't know if there's any facility for the jetty dirs outside of that to get deleted
zzz
maybe there is, maybe not, but there's a reason I put the jetty temp inside the i2p temp, so we wouldn't have to worry about it
dr|z3d
yeah, it's the i2p tmp dirs that aren't getting removed here.
dr|z3d
(and everything therein)
zzz
happy bug hunting :)
dr|z3d
thanks for that :)
dr|z3d
I may just set a fixed name for the i2p tmp dir instead, so whatever's in there gets overwritten.
zzz
no that's a security issue
zzz
its random for a reason
dr|z3d
ok
zzz
local attacker creates your temp dir, puts stuff in it, looks at your files, etc etc
dr|z3d
so then it's probably the amount of time I'm giving the router to cleanup on restart.
dr|z3d
there's no way of blocking the restart until shutdown tasks are completed? currently we just set a wait period, which seems sub-optimal.
zzz
we do wait, but not forever, because we don't want buggy plugins (*cough* str4d and sponge) or snark with a million torrents to block it
dr|z3d
ok :)
zzz
but if you're messing with the router shutdown code and timeouts, that seems like a bad idea
dr|z3d
could be blocking for tasks that we know aren't going to take forever, and no, I'm not messing with that code right now. *chuckle*
dr|z3d
well, not much. I've tweaked the wait period in the wrapper, but that was some time ago. may have to revisit that. and I've tweaked the LIVELINESS_DELAY so we're not waiting almost a minute to verify there's no other router running, which seems excessive.
zzz
it's a minute because that's how often we write the ping file
zzz
and it's a rare case anyway
zzz
anyway, I fell into a "burst throttler" rabbit hole, doing research, looks like it's gonna be another big ticket
dr|z3d
currently looking at the I2PTunnelRunner and related OutproxyRunner
dr|z3d
initial subjective impressions on the mods look good, much lower latencies on outproxy page loads.
dr|z3d
if you get something working reliably with persistent connections, I wouldn't mind having a look. complimentary to what I'm up to.
zzz
yeah I figured that
zzz
I did one cleanup pass in anticipation but I have another one to do, there's some possible websocket tangled in
zzz
from early this year that I need to test separately and extract from the persistence stuff
zzz
*websocket fixes
zzz
what i2ptunnelrunner mods?
dr|z3d
for the outproxyRunner, I'm using a buffered output stream and larger buffers.
dr|z3d
(and flushing less frequently)
zzz
this is for the local outproxy plugin, right?
dr|z3d
yup, and for the I2PTunnelRunner, which is slightly different, mod-wise. just larger buffers there, and less flushing.
zzz
seems unlikely buffer increase would help, and InternalSocket is already buffered
zzz
you're never gonna see measurable improvements with buffer size changes, imho, it's just an efficiency thing
dr|z3d
oh, and max packet size.
dr|z3d
having to copy to a new buffer because you've outgrown the current buffer adds some latency, no?
zzz
maybe tor is fast enough that you could see it, but I'm skeptical
zzz
no that's not how it works
zzz
it's just how much you read and write at a time. you don't "copy to new buffer", you don't "outgrow"
zzz
it's the _max_ you read before writing. when you don't have anymore to read, then you write, even if less than max
zzz
this is taking hours to understand the new throttlers
dr|z3d
oh dear, oh dear. that doesn't bode well. I haven't yet adopted all that code, so I'm using something a lot simpler.
zzz
just a reminder to everybody, all the 2.3.0-x dev builds to date have severe memory leaks, testers should restart every few days
dr|z3d
y23kboy noticed that, I looked at his mem usage graph and thought it was the normal gc cadence.
zzz
That's ticket #406. Progress is slow and I keep finding more causes
zzz
Until it's resolved it's hard to recommend testing for people that are running services
zzz
#453 for the throttlers
zzz
hmpf, the new t-bird broke sending gpg emails for me
zzz
I think the root cause may be this and will have to wait a couple weeks for mantic to fix it? groups.google.com/g/linux.debian.bugs.dist/c/3_UL9JlTZCI
dr|z3d
you on mantic now?
zzz
no I don't do prerelease
zzz
won't be long though
dr|z3d
geeky-gadgets.com/ubuntu-mantic-minotaur | howtogeek.com/ubuntu-linux-2310-mantic-minotaur-is-now-available
dr|z3d
canonical.com/blog/canonical-releases-ubuntu-23-10-mantic-minotaur | linuxiac.com/ubuntu-23-10-mantic-minotaur
dr|z3d
you get the idea. it's released!
zzz
great. not sure how long the delay is before it shows up in the updater. I'll wait for that
dr|z3d
anyone using an outproxy, either purokishi or stormycloud, can you test canonical.com/blog/canonical-releases-ubuntu-23-10-mantic-minotaur
dr|z3d
I'm seeing an ocsp server error, but it might be a local issue.
dr|z3d
interesting, in firefox if security.OCSP.enabled is set to 0, then the site loads fine. could be an issue accessing over the outproxy.