@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+not_bob
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb_
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
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