NPE stack trace in otherwise normally functioning mesh node
stewart.allen
Ian Barfield
It's a known problem. Basically if a stream completes and cleans up it's stream tracking meta bizz, then receives a send_more signal, it ends up creating a new target object which never gets initialized properly (because those signals were already received). I fixed this by implementing explicit stream creation frames. So if a send_more is received and there is no existing target, it won't just make a blank one and hope for the best. Unfortunately, due to some less than robust error handling it is not only incompatible but tends to severely injure mesh nodes from older versions. This made things difficult for some of my users, so I ended up changing the flag that enables that fix to default to off.
http://pastebin.com/NpSmrnrz
--
You received this message because you are subscribed to the Google Groups "hydra-oss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hydra-oss+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Stewart Allen
Ian Barfield
Well it depends what version of mesh you are running I suppose. I implemented the fix a while ago. You just need to set a certain system property and make sure all the mesh using processes do the same.
Stewart Allen
Ian Barfield
meshy.source.noCreationFrames: false
Stewart Allen
meshy.source.noCreationFrames: false
Ian Barfield
It made more sense when it defaulted to false and you had to set it to true. Just creationFrames would be cleaner but it sort of implies you might actually want to toggle it for some reason. "noCreationFrames true" reads more like a "specific work around" flag. Maybe I over think these things though.