@eyedeekay
&zzz
+Irc2PGuest51117
+Irc2PGuest90409
+acetone
+dr|z3d
+eche|off
+nilbog
+orignal
+postman
+qend-irc2p
+sourceress
Arch
Danny
Irc2PGuest23180
Irc2PGuest35290
Irc2PGuest36302
Irc2PGuest39635
Irc2PGuest49364
Irc2PGuest6564
Irc2PGuest67278
Irc2PGuest71245
MatrixBot
Onn4l7h
Over
Sleepy
Teeed
Yotsu
_bob_
aargh3
ac9f
ahiru
ananas2
anontor2
b3t4f4c3__
cims
dr4wd3_
duanin2
eyedeekay_
f00b4r
ghirolt
hababam
leopold
major
marek
n2_
noidea
not_bob_afk2
nyaa2pguy
o3d3_
profetikla
r00tobo
rapidash
solidx66
stormycloud[m]
test7363673
uop23ip
user_
w8rabbit
zelgomer
RN
I'd need to change the wrapper logging if it even has the info available
obscuratus
There's a lot of configuration available for the wrapper.
RN
yeah, lots
RN
ugh
RN
and router needs to be shut down before editing wrapper.config right?
obscuratus
Not sure, but it certainly needs to be re-started to update the config changes.
dr|z3d
yeah, you can edit the wrapper while the router's running, but you need to stop and start the router to effect the changes.
dr|z3d
that is, stop router, start router. NOT restart router :)
obscuratus
Oh, yeah, good point.
dr|z3d
the wrapper handles the restart process, so won't get its configs updated if you just restart.
RN
riiiiight
RN
darn I tried a restart... might have fixed it already
RN
LOL
RN
hmmm... 25 part tunnels... the VM is performing pretty well for fairly short uptime
RN
well, it happens at load right after the jbigi line
RN
still no listing of file
RN
set wrapper logging to info and still no clue of the file
RN
pfft
dr|z3d
check the usual suspects in ~/.i2p/eepsite and subdirs containing jetty xml files.
RN
I've been through all of them and ran them all through dos2unix
RN
and diffed them to the ones in ~/i2p
RN
only change is setting 7658 to 0.0.0.0 since this is on a vm
dr|z3d
wouldn't worry about it then. nothing's not working as expected, is it?
RN
everythign's been working fine. I was just surprised to see that error on the VM also
RN
me and my headscratchers!
RN
LOL
dr|z3d
you just like distracting yourself from doing more meaningful things *cough*
RN
it's not a matter of like, more of an ocd thing
RN
but I did get rsync into the vm set up, so I can tinker with what you are encouraging me to on there and copy it out when ready to deploy
obscuratus
eyedeekay: Were you going to do Issue #406 (FNDS memory leak, subDb's shut down), or do you want me to look at it.
obscuratus
I started, and have some ideas, but don't want to waste my time if you've already got something going.
obscuratus
Ick! I just noticed something. Unpublishing the LS needs to be re-worked. The connections have already been closed by the time we get to the point in the code where we normally unpublish a LS.
obscuratus
Unpublish through exploratory tunnels?
obscuratus
Oh, I see, it's not something that goes out. Just supposed to be removal from the datastore in <=2.3.0
eyedeekay
I am working on one but I am as always open to any helpful ideas
obscuratus
You may need the helper I put in there so that you can find the dbid provided the LS key.
obscuratus
All the netDb() calls in clientConnectionRunner were probably going to the main netDb. They'd need to be re-targetted.
obscuratus
And I just realized that unpublish has room to be re-imagined since we about the destroy the datastore and netdb anyways.
obscuratus
anyhow, in FloodfillDatabaseNetworkSegmentor, public String getDbidByHash(Hash clientKey)
eyedeekay
Thanks I see
eyedeekay
What I am having trouble with is when/how do we know when to delete a stale client DB
obscuratus
My thought was to do it proximate to where we unpublish in ClientConnectionRunner.
obscuratus
As I think it through further, unpublish might be able to be reworked to just destroy the client facade.
eyedeekay
Does unpublish get called if the client was never published?
obscuratus
I've been going through the logs of shutting down a service, I2pSnark, shared clients. They all seem to us clientConnectionRunner as a central part of the shutdown.
obscuratus
There's a portion in clientConnectionRunner::stopRunning() that uses the conditional: if (_context.netDb() != null) { (Line 214)
obscuratus
Of course that conditional is (ahem!) wrong since that's for the main db. :)
obscuratus
I think unpublish only removes it from the local DS (in the <=2.3.0 context).
obscuratus
So both unpublished and published LS are removed.
eyedeekay
Yeah must have been pretty tired to miss that one
obscuratus
Anyways, there's not much point in replicating the old unpublish functionality since we're about to free up that client netDb.