@eyedeekay
&eche|on
&zzz
+Irc2PGuest3601
+R4SAS
+RN
+StormyCloud
+cumlord
+dr|z3d
+eche|off
+mareki2p
+not_bob_afk
+orignal
+postman
+qend-irc2p
Arch2
Birdy
BubbRubb
Chrono
Dann
DeltaOreo
Irc2PGuest2010
Irc2PGuest20149
Irc2PGuest57895
Irc2PGuest74254
Irc2PGuest90985
Irc2PGuest95708
Irc2PGuest98006
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
SlippyJoe
Stormycl1
T3s|4_
Teeed
aargh2
ac9f_
acetone_
anontor
b3t4f4c3__
dr4wd3
duanin2
duck
eyedeekay_bnc
gelleger1
leopold_
makoto
matean
n1
nilbog-
poriori
profetikla
r00tobo_BNC
rapidash
shiver_
snex
solidx66
thetia
u5657
uop23ip
w8rabbit
x74a6
xHarr
eyedeekay
Do we really want to create a new peer selector every time we run a store job?
eyedeekay
It looks like the only thing createPeerSelector is used for is to instantiate _peerSelector, which is final, so if _peerSelector is already instantiated should createPeerSelector return _peerSelector instead?
obscuratus
eyedeekay: Hhhhmm, I didn't notice I was creating a new peer selector each time a job was created. Yeah, there must be a cleaner way to do that.
eyedeekay
I tried the thing I said, I seem to be connected still
eyedeekay
If one exists on the facade it got, the behavior is identical to get, otherwise returns a new one
obscuratus
Right now, I'm leaning towards putting the creation of the peer selector into the constructor (or initialization of the subDb).
obscuratus
Then, no need for a function to create the peer selector.
obscuratus
Of course, if we end up with some fashion of not including RI in the subDbs, that would end up a depricated function.
obscuratus
eyedeekay: I'm seeing something in my logs while testing subdbs, and I want to confirm if you're seeing the same thing.
obscuratus
It looks like everytime we start a new client (and, start a new subdb), we triggering a rebuild of our own RI, and publishing and flooding out our RI.
obscuratus
Kind of like broadcasting to the world that we're the router that just started up this secret service. :D
robin
eyedeekay, I put a DEBUG call into SAMv3DatagramServer.java to print any message received. It never gets called. I wonder if the V3 SAM handler is hooked to my session at all.
robin
I am adding another call right at the top of the 'run' method to see if it ever starts
robin
eyedeekay, the 'run' method in SAMv3DatagramServer is never called, so my UDP messages are going somewhere else
eyedeekay
you're right once again, thanks, I think I know where it happens, I'll fix it tonight