Status: Accepted
Owner: [hidden email] Labels: Milestone-1.3 New issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 Pharo 1.3 fails to load the DejaVu package which is a very big package. MCHttpRepository location: 'http://www.squeaksource.com/DejaVu' user: '' password: '' ok in 1.2 _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #1 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 MC uses Zn through HTTPSocket since 1.3 That means that the global Zn timeout setting is used, 10s. See ZnNetworkingUtils, #socketStreamTimeout and #setSocketStreamParameters: I am not sure how we have to solve this, any suggestions ? Sven _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #2 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 We should increase probably. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #3 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 I've tried with 30s instead of 10s and the package loaded ok. so, it seems that it is more a UI problem: - maybe we should have a setting for the timeout (and for the socket buffer size ?) - maybe that in case of timeout, we shouldn't fall into an error (opening the degugger) but with a dialog [cancel/retry]. what do you think ? Alain _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #4 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 just increasing a global timeout is not a good idea, in general I want to know in a couple of seconds that SS is down for example, I don't want to wait 1 minute before the timeout is thrown. there will always be cases (huge downloads, slow internet) where the default time is too low. this is both a specification/API problem and a UI problem: Zn allows setting a specific timeout per request, but not everywhere, MC goes through HTTPSocket where such specification is not possible. There could be a notification asking you if you want to wait more, but that should be done so that it can work headless as well. Could we make throwing a timeout a resumable exception ? Sven _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: -Milestone-1.3 Milestone-1.4 Comment #5 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 throwing an exception would allow clients to react at the right level. so ok for me. not a show stopper for 1.3 since I think. -> 1.4 Alain _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: -Milestone-1.4 Milestone-1.3 Comment #6 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 I am getting it know when doing a 1.3 update.. it stops with a timeout, even though all .mcz files have been uploaded. Maybe reading the index of all the 4000 versions now takes so long that it times out? This is really annoying. I move this to 1.3 for now. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #7 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 Pressing "proceed" works... so we can at least continue to do updates ;-) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #8 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 Marcus, OK, that is great (that you can proceed the exception). Would it also not be possible to write a handler around the problem areas so that this behavior can be enforced programmatically ? Ideally something like <SomeUtilClass>#do: <block> withExtendedTimeout: 5 minutes that keeps on swallowing and resuming/proceeding ConnectionTimedOut exceptions until the extended timeout expires ? Sven _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #9 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 How should I write that because right now I cannot commit changes to morphic package because after the timeout I get subscript.... our of bounds.. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #10 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 as a workarround, you can increase the timeout delay. change ZnNetworkingUtils>>socketStreamTimeout Alain _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #11 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 Thanks I will put it to 30 for now. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #12 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 What about a DynamicVariable ? ZnConnectionTimeout value: 30 seconds during: [ ZnClient get: 'http://slowhost.com/foo' ] It is a hack as well, but it could work. I am just not sure about DynamicVariable, it does not seem to be used a lot... Sven _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #13 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 why not :) Now I will hange the method itself. so that we can move and we have the time to think. We could first have a variable instead of a method returning a constant. _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #14 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 For the moment I would like something really simple and robust. So I added a class Variable in 13240 _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #15 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 do we add a setting for it ? _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: Type-Bug Comment #16 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 (No comment was entered for this change.) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Labels: -Milestone-1.3 Milestone-1.4 Comment #17 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 I think for 1.3, this is good enough.... I classify this for 1.4 _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Comment #18 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components: http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenberghe.168.mcz ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.168 Author: SvenVanCaekenberghe Time: 18 June 2011, 11:12:18 pm UUID: dbe15895-070d-4a2f-8d62-dd40c5ba028a Ancestors: Zinc-HTTP-SvenVanCaekenberghe.167 introduction of ZnConnectionTimeout which is used by ZnNetworkingUtils class>>#socketStreamTimeout and defaults to ZnNetworkingUtils class>>#defaultSocketStreamTimeout Now you can do ZnConnectionTimeout value: 60 seconds during: [ ZnClient get: 'http://slowhost.com/foo' ] _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Updates:
Status: FixProposed Labels: -Milestone-1.4 Milestone-1.3 Comment #19 on issue 4326 by [hidden email]: Connection timeout problem http://code.google.com/p/pharo/issues/detail?id=4326 (No comment was entered for this change.) _______________________________________________ Pharo-bugtracker mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker |
Free forum by Nabble | Edit this page |