@eyedeekay
&eche|on
&kytv
+R4SAS
+RN
+acetone
+dr|z3d
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
FreefallHeavens
Gid
Irc2PGuest13560
Irc2PGuest1893
Irc2PGuest32938
Irc2PGuest4253
Irc2PGuest8259
Leopold
Minogami
Onn4l7h
Sleepy
Soni
T3s|4_
Teeed
aargh1
admin
anon4
apt0110
b3t4f4c3__
cheddah
eyedeekay_bnc
idk
itsjustme_
j6
limak
not_bob_afk
polistern
poriori_
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
u5657
user100
x74a6
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.