&eche|on
&zzz
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+eche|off
+not_bob_afk
+orignal
+postman
+snex
+wodencafe
Arch
BubbRubb
Chrono
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest16752
Irc2PGuest33667
Irc2PGuest51880
Onn4l7h
Over
Sisyphus
Sleepy_
Teeed
aargh2
ac9f_
b3t4f4c3__
b4dab00m
bak83_
duanin2
duck
john231
leopold
makoto
mareki2p_
nilbog-
poriori_
profetik1
r00tobo
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
vivid_reader56
x74a6
xHarr
Irc2PGuest40217
Defintion: skift - a little boat that is running late
dr|z3d
:)
dr|z3d
got a java.lang.NumberFormatException issue, zzz. i2ptunnel.jar doesn't like b64s piped to ping with a leading -
zlatinb
the rekeying happened again. It seems that it's happens always after extended downtime if firewalled
zlatinb
extended == about a day
zlatinb
zzz: boy do I have a deadlock for you e7qy5kc7ivqtnrbdn5ymx5nmbdedlrjkdchqmmkhud4ockrime5a.b32.i2p/?39144d850bd442b7#5cDzAXbqEwdgHjs9Urf7zePXPt26wLB3bH5rRVacjgxT
zlatinb
3 threads this time
zzz
zlatinb, that looks like an equivalent deadlock as yesterday, in getPorts(), are you running with the fix, because it doesn't look like it
zlatinb
no, still 1.7.0
zlatinb
it's hard to update to git build when running an embedded router
zzz
re: rekeying, I think I finally see why it's happening
zzz
checkin yesterday prevented the rekeying but this one fixes the root cause
zlatinb
I'm not sure I follow the logic but I'll update my standalone router and give it a few days
zzz
yeah it's 100% reproducible for me now so I'm pretty sure I got it
zlatinb
how do you reproduce it?
zzz
firewalled peer, shutdown for an hour, like you said
mesh
zzz: hey, did you see git.idk.i2p/mesh/i2p.i2p/-/issues/5 ?
zzz
whataboutit
mesh
what do you think? is that something that could happen?
zzz
we already discussed it
zzz
since you have a workaround, it's low priority
mesh
the split packages are a big pain and there's no good work around. I figure renaming them on your end is the easiest solution but not sure what the impact might be
zzz
if you don't want us to forget about it, create an issue on our repo, not yours
zzz
you said that putting apache first in the classpath was an effective workaround
mesh
zzz: if we keep apache components off the modulepath and ahead of i2p on the classpath it will "work" but this isn't really a solution
zzz
so you agree it's an effective workaround for now?
mesh
zzz: for developers running code inside eclipse it will work. I don't think it makes sense to even try to release to users like this
mesh
before we do a bunch of work trying to hack around this, I guess the question is, is this something that could be fixed on your end in the near future? I imagine a package rename should be a simple affair but I don't know the impact
zzz
it's been like that for 7 years, you're the first to complain
zzz
as I said, I assess it as low priority. the way to get something fixed is to put an issue on our repo and state your case, not by bugging me
mesh
alright created git.idk.i2p/i2p-hackers/i2p.i2p/-/issues/353
zzz
thank you
obscuratus
I had some intermittent success replicating the re-keying issue on start-up last night on -13, but I just tried to replicate with -14, and didn't run into any occurances.
T3s|4
o/ zzz: some minor end-user input: when running -13 against fully updated ArchLinux with java-18-openjdk (default), I see nothing unusual or of concern
zzz
thanks obscuratus I'm optimistic I finally got it
zzz
thanks T3s|4 not expecting any issues with 18, I know zlatinb is testing also
T3s|4
thanks zzz, good to know, but I will report if 'new' problems appear so you can have a look
zzz
ok. rumor has it that it uses less memory