Re: [freenet-support] http fproxy ports are not closed
On Fri, 2 Sep 2011 00:23:00 -0400, Dennis Nezic wrote: On Wed, 31 Aug 2011 15:02:14 -0400, Dennis Nezic wrote: On Wed, 31 Aug 2011 09:44:17 -0400, Dennis Nezic wrote: netstat (netstat -pnat | grep java) shows 213 connections to my fproxy at 127.0.0.1:, in a CLOSE_WAIT state. I only noticed this after I could no longer access fproxy -- probably because of some thread or connection limit. I'm not exactly sure how to reproduce this -- it's not simply a matter of opening a connection to fproxy. False alarm. I think my freenet wget spider got out of control. Apologies. Upon further consideration, I think it might actually be a bug. For one thing, this never happened with earlier pre-1401ish versions. For another thing, why are there so many sockets open, when my wget client has long since closed and exited? (it has been about half an hour now -- I'll provide updates if they ever do close.) CLOSE_WAIT apparently means fproxy got the FIN signal from my wget, but didn't close it's end? I'm still not sure exactly how this bizarre behavior (of not closing sockets) starts -- because if I restart freenet, and do a simple wget transaction, the socket does get properly closed. All those HTTP socket handlers are still open and consuming freenet threads. They were initiated by wget localhost:/USK... type calls -- and they probably failed because the sites were old. Normal browser access to control localhost: does still close the socket properly. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] http fproxy ports are not closed
On Friday 02 Sep 2011 13:20:39 Dennis Nezic wrote: On Fri, 2 Sep 2011 00:23:00 -0400, Dennis Nezic wrote: On Wed, 31 Aug 2011 15:02:14 -0400, Dennis Nezic wrote: On Wed, 31 Aug 2011 09:44:17 -0400, Dennis Nezic wrote: netstat (netstat -pnat | grep java) shows 213 connections to my fproxy at 127.0.0.1:, in a CLOSE_WAIT state. I only noticed this after I could no longer access fproxy -- probably because of some thread or connection limit. I'm not exactly sure how to reproduce this -- it's not simply a matter of opening a connection to fproxy. False alarm. I think my freenet wget spider got out of control. Apologies. Upon further consideration, I think it might actually be a bug. For one thing, this never happened with earlier pre-1401ish versions. For another thing, why are there so many sockets open, when my wget client has long since closed and exited? (it has been about half an hour now -- I'll provide updates if they ever do close.) CLOSE_WAIT apparently means fproxy got the FIN signal from my wget, but didn't close it's end? I'm still not sure exactly how this bizarre behavior (of not closing sockets) starts -- because if I restart freenet, and do a simple wget transaction, the socket does get properly closed. All those HTTP socket handlers are still open and consuming freenet threads. They were initiated by wget localhost:/USK... type calls -- and they probably failed because the sites were old. Normal browser access to control localhost: does still close the socket properly. Well what are they doing then? Still running the requests? This is a fundamental problem with fetching stuff over HTTP from Freenet with a low timeout - if your tool moves on to add more requests, the old requests haven't failed, they are still going. Having said that it may eventually be possible to detect connection closed - in 0.5 there was a hack for it. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet 0.7.5 build 1401
On Saturday 27 Aug 2011 11:30:46 CyberLeo wrote: On 08/26/2011 10:50 AM, Matthew Toseland wrote: Freenet 0.7.5 build 1401 is now available. Please upgrade, it will be mandatory at midnight. This build turns off New Load Management, for the time being. If performance continues to be poor we will know the problem is elsewhere (it is possible that it is a problem with the asyncGet changes, although I don't see how). There are also fixes related to dropping peers due to the one IP per connection setting. You should not normally enable this setting on darknet (core settings); it can cause your friends to be lost. Thanks, and sorry for all the problems lately. I just noticed this warning appearing today on my FreeBSD-native node, running 1401. Everything seems to be running alright, so I'm not sure how accurate the message might be (aside from the strange rejection of a Sun Java implementation because it is not a Sun Java implementation). Is this bug-worthy? 8 You are trying to run Freenet under a non-Sun/Oracle Java: Sun Microsystems Inc. 1.6.0 (OpenJDK 64-Bit Server VM). This is not recommended: Freenet may not run well. Please get Sun/Oracle Java from http://www.java.com/getjava/ if possible. 8 I had just switched Java versions yesterday to get rid of the huge red XML vulnerability message I was receiving with the official Sun JDK. Yes, sorry, they're both okay (it turns out the big red warning is unnecessary, and most versions of OpenJDK work fine too). signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] http fproxy ports are not closed
On Fri, 2 Sep 2011 14:40:22 +0100, Matthew Toseland wrote: On Friday 02 Sep 2011 13:20:39 Dennis Nezic wrote: On Fri, 2 Sep 2011 00:23:00 -0400, Dennis Nezic wrote: On Wed, 31 Aug 2011 15:02:14 -0400, Dennis Nezic wrote: On Wed, 31 Aug 2011 09:44:17 -0400, Dennis Nezic wrote: netstat (netstat -pnat | grep java) shows 213 connections to my fproxy at 127.0.0.1:, in a CLOSE_WAIT state. I only noticed this after I could no longer access fproxy -- probably because of some thread or connection limit. I'm not exactly sure how to reproduce this -- it's not simply a matter of opening a connection to fproxy. False alarm. I think my freenet wget spider got out of control. Apologies. Upon further consideration, I think it might actually be a bug. For one thing, this never happened with earlier pre-1401ish versions. For another thing, why are there so many sockets open, when my wget client has long since closed and exited? (it has been about half an hour now -- I'll provide updates if they ever do close.) CLOSE_WAIT apparently means fproxy got the FIN signal from my wget, but didn't close it's end? I'm still not sure exactly how this bizarre behavior (of not closing sockets) starts -- because if I restart freenet, and do a simple wget transaction, the socket does get properly closed. All those HTTP socket handlers are still open and consuming freenet threads. They were initiated by wget localhost:/USK... type calls -- and they probably failed because the sites were old. Normal browser access to control localhost: does still close the socket properly. Well what are they doing then? Still running the requests? This is a fundamental problem with fetching stuff over HTTP from Freenet with a low timeout - if your tool moves on to add more requests, the old requests haven't failed, they are still going. They will go on forever? Fproxy will never close them? (Sounds pretty easy to DDOS that?) And why didn't this happen before? Having said that it may eventually be possible to detect connection closed - in 0.5 there was a hack for it. I think tcp's CLOSE_WAIT means fproxy should have already gotten a close signal, no? ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
