Bumping this to the top. The bug is still in latest unstable. /N ----- Original Message ----- From: "Niklas Bergh" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 08, 2003 3:29 PM Subject: [freenet-dev] null stream from buffer, possible explanation
> For a long time fred has now and then generated 'null stream from buffer' > exceptions (stacktrace #2 below). I think I might finally have tracked down > the reason. > > If I interpret the stacktrace #2 below (the actual error that can be found > in the log file) the exception occurs when our node receives inserted data > which it is supposed to relay on to another node (by dumping the data into > the store and then sending it on from there it would seem). > > The only reason that a freenet.fs.dir.NativeFSDirectory$ExternalNativeBuffer > returns a 'null stream' is that its release() method has been called at some > point in time (meaning that it has been closed). Stacktrace #1 below shows > when the ExternalNativeBuffer returning the 'null stream' had its release() > method called. I took some timestamps when I recorded these exceptions and > they show that the ExternalNativeBuffer:s might be release():d from anywhere > between 1 to 200 seconds or so before the data to be relayed arrived to my > node (which is when Stacktrace #2 occurs). > > I cannot do very much more about this since I dont know the statechains or > the protocol well enough for that.. I am not totally sure that this > actually CAUSES inserts to fail though.. I think that this message is an > effect of an already failed insert or so.. ***I would be happy if toad could > have a look at this to verify that this conclusion is correct though*** > > Another couple of thoughts that follows given that my conclusion is correct: > Is there any harm done if we would actually keep the data that we are about > to receive (maybe this would cause the inserter to believe that his insert > succeeded when it actually didn't, which isn't a good thing I assume)? Maybe > the handleThrowable() call in the SendData state (stacktrace #1) should be > avoided (or made not releasing the ExternalNativeBuffer or something). Or > maybe, just maybe.. we should tell the inserting node (the one we recieve > the data from in stacktrace #2) that it shouldn't bother to send us any data > since we wont accept it already somewhere during Stacktrace #1?! Since my > timestamps shows that the time between Stacktrace #1 and number #2 might > well be counted in minutes this might be well worth the effort (doing that > will prevent the inserter from waiting in vain for his insert to complete > and will stop the insert from consuming unnecessary bw).. > > Regards > /N > > ---Stacktrace #1--- > java.lang.Exception: buffer released > at > freenet.fs.dir.NativeFSDirectory$ExternalNativeBuffer.release(NativeFSDirect > ory.java:1589) > at freenet.node.ds.FSDataStoreElement.release(FSDataStoreElement.java:75) > at > freenet.node.ds.FSDataStoreElement$KeyInputStreamImpl.close(FSDataStoreEleme > nt.java:301) > at freenet.node.states.data.SendData.handleThrowable(SendData.java:257) > at freenet.node.states.data.SendData.received(SendData.java:179) > at freenet.node.StateChain.received(StateChain.java:190) > at freenet.node.StateChain.received(StateChain.java:71) > at > freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler.java:2 > 26) > at > freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHandler.j > ava:165) > at > freenet.node.StandardMessageHandler$Ticket.access$0(StandardMessageHandler.j > ava:145) > at > freenet.node.StandardMessageHandler.handle(StandardMessageHandler.java:71) > at freenet.Ticker$Event.run(Ticker.java:284) > at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:270) > > ---Stacktrace #2--- > 2003-okt-07 23:40:20 (freenet.node.Node, QThread-2114, ERROR): Error while > receiving message freenet.Message: Accepted > @[EMAIL PROTECTED] for tcp/connection: > 4216>68.35.63.240:19139,[EMAIL PROTECTED],freenet.sessi > [EMAIL PROTECTED], sending null @ af58c44c3cb2008b in state > freenet.node.states.request.TransferInsertPending: > key=8da48d007a1a5c337b9860ed5a96a451ac4c36910f0203, hopsToLive=6, > id=af58c44c3cb2008b, [EMAIL PROTECTED] > (8da48d007a1a5c337b9860ed5a96a451ac4c36910f0203,insert),ft=freenet.node.stat > [EMAIL PROTECTED]@1065562820187, routedTime=1065562819734, > replyTime=-1, not-approved, insertReplyTime=-1: > java.lang.IllegalStateException: null stream from buffer > [EMAIL PROTECTED]:null > java.lang.IllegalStateException: null stream from buffer > [EMAIL PROTECTED]:null > at > freenet.node.ds.FSDataStoreElement$KeyInputStreamImpl.<init>(FSDataStoreElem > ent.java:238) > at > freenet.node.ds.FSDataStoreElement.getKeyInputStream(FSDataStoreElement.java > :47) > at > freenet.node.ds.FSDataStoreElement$KeyOutputStreamImpl.getKeyInputStream(FSD > ataStoreElement.java:138) > at > freenet.node.states.data.ReceiveData.getKeyInputStream(ReceiveData.java:69) > at > freenet.node.states.request.InsertPending.relayInsert(InsertPending.java:345 > ) > at > freenet.node.states.request.TransferInsertPending.receivedMessage(TransferIn > sertPending.java:213) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at freenet.node.State.received(State.java:126) > at freenet.node.StateChain.received(StateChain.java:190) > at freenet.node.StateChain.received(StateChain.java:71) > at > freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler.java:2 > 26) > at > freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHandler.j > ava:165) > at > freenet.node.StandardMessageHandler$Ticket.access$0(StandardMessageHandler.j > ava:145) > at > freenet.node.StandardMessageHandler.handle(StandardMessageHandler.java:71) > at freenet.Ticker$Event.run(Ticker.java:284) > at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:270) > > _______________________________________________ > Devl mailing list > [EMAIL PROTECTED] > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl > _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
