Synnefo

Vangelis Koukis wrote:

Όχι, δεν ξεκινάει.
Με: Version: 9.0.8112.16421, Update Versions: RTM (KB982861), σε Windows Vista SP2.

Δεν είπα τι κάνει: Φορτώνει [ενίοτε] την αρχική σελίδα, βγάζει τον spinner, είναι τελείως unresponsive [δίνει την εντύπωση κολλημένης Javascript που από πίσω έχει άπειρα να κάνει], μετά από 10sec περίπου βγάζει ειδοποίηση "the page at xxx.yyy.zzz is unresponsive" και με προτρέπει να σκοτώσω το tab.

Vangelis Koukis wrote:

Το αρχικό πρόβλημα που υπήρχε όταν άνοιξε το ticket, είχε να κάνει με τα διαφορετικά http headers που παίρνει ο explorer σε σχέση με τους υπόλοιπους browsers (και συγκεκριμένα η χρήση του Date).

Δεν το καταλαβαίνω αυτό. O Internet Explorer δεν λαμβάνει από τον HTTP server ακριβώς την ίδια απάντηση με τους υπόλοιπους browsers; πώς γίνεται αυτό; ο server αλλάζει την απάντηση ανάλογα με το ποιος έρχεται; το Date είναι υποχρεωτικό πεδίο σε μια απάντηση HTTP.

την ίδια απάντηση υποθέτω κι εγώ πως θα λαμβάνει, όμως η getAllResponseHeaders() στον ΙΕ δεν περιέχει το Date.

Πλέον δεν χρησιμοποιείται το Date header γι αυτό και έχει φύγει το error που πετούσε.

Πώς γίνεται να μη χρησιμοποιείται το Date από το UI; πώς δουλεύει το ?changes-since?
Πώς ξέρει από πότε και μετά να ζητήσει τις αλλαγές; Σε ποιο commit μπήκε η μη χρησιμοποίηση του Date και γιατί;

Για να μην υπάρχει πρόβλημα, το server date πλέον έρχεται από το Django ώστε να μην είναι browser dependend. Κατά τα άλλα δεν αλλάζει κάτι στη χρήση του changes-since. To commit είναι το 54479111

Μήπως έχεις κάποιο add-on που δημιουργεί κάποιο conflict?

Απενεργοποίησα τρεις accelerators άσχετους, απενεργοποίησα το Adobe PDF extension, υπάρχει μόνο το extension της Java που δεν έχει κάνει ποτέ πρόβλημα και δεν εμπλέκεται στην αρχική σελίδα.

Έχει την ίδια συμπεριφορά.

Θέλει παραπάνω ψάξιμο, σε διαφορετικά μηχανήματα [θέμα timing/Javascript/race condition/αριθμού επεξεργαστών].

Όντως μάλλον θέλει testing σε περισσότερα μηχανήματα. Θα δοκιμάσω το βράδυ πάλι που θα έχω πρόσβαση σε ένα 3ο laptop (οι δοκιμές σε 8 και 9 έγιναν σε διαφορετικά) να δω κι εκεί τι συμπεριφορά έχει.

Mike Muzurakis wrote:

Vangelis Koukis wrote:

την ίδια απάντηση υποθέτω κι εγώ πως θα λαμβάνει, όμως η getAllResponseHeaders() στον ΙΕ δεν περιέχει το Date.

Αυτό είναι bug του IE; Αν ναι ποιο, υπάρχει reference; αν όχι, πρέπει να φτιαχτεί.
Ο IE λαμβάνει ακριβώς την ίδια απάντηση όπως οι άλλοι browsers. Δεν μπόρεσα να βρω αναφορά σε διαφορετική συμπεριφορά του σε σχέση με αυτούς με ένα βιαστικό ψάξιμο στο δίκτυο.

Για να μην υπάρχει πρόβλημα, το server date πλέον έρχεται από το Django ώστε να μην είναι browser dependend. Κατά τα άλλα δεν αλλάζει κάτι στη χρήση του changes-since. To commit είναι το 54479111

Η λογική πίσω από αυτή την αλλαγή είναι εντελώς λάθος και θα φύγει.
Έπρεπε να είχε συζητηθεί, κι όχι να είχε έρθει σχεδόν από τύχη στη συζήτηση.

Η σχεδίαση είναι ξεκάθαρη, το UI κάνει κλήσεις μόνο σε API endpoints. Η εισαγωγή του νέου URL /datetime βάζει από το παράθυρο μια κλήση στο Django που το κάνει ασύμβατο με ο,τιδήποτε άλλο, και προκαλεί προβλήματα concurrency. Το UI παίρνει κανονικά Date: header, σε αυτό θα βασίζει τις επόμενες ερωτήσεις του. Έχει αναλυθεί με ακρίβεια στα σχετικά tickets

Η αλλαγή του commit αυτού φεύγει άμεσα, ο ΙΕ θέλει έξτρα δουλειά για να δουλεύει σωστά. Αν δεν δουλεύει με το Date:, είναι πάρα πολύ σοβαρό bug του και πρέπει να βρεθεί authoritative αναφορά που να το επιβεβαιώνει.

Όντως μάλλον θέλει testing σε περισσότερα μηχανήματα. Θα δοκιμάσω το βράδυ πάλι που θα έχω πρόσβαση σε ένα 3ο laptop (οι δοκιμές σε 8 και 9 έγιναν σε διαφορετικά) να δω κι εκεί τι συμπεριφορά έχει.

Συμπλήρωσε το ticket όταν έχεις νέα δεδομένα, γενικά μεγάλο μέρος της ομάδας έχει Windows οπότε και IE , άρα δεν θα λείψουν οι δοκιμές.

ξέχασα να πρσοθέσω πριν, για να μην χρειάζεται να διαβάσει κανείς όλα τα λινκς, το πρόβλημα είναι pvw στα ajax requests o IE cacharei κάποια headers. Γι αυτό και η σελίδα εμφανίζεται την 1η φορά και στο refresh έχει error.

Mike Muzurakis wrote:

Στο c8bde382 πρόσθεσα το cache: false στο request της jQuery. Ε

Στην ουσία κάνει το ίδιο με το workaround παραπάνω, αλλάζει το get request απλά γίνεται με ποιο standard τρόπο μέσω της jquery. Μας ικανοποιεί αυτή η λυση;

Η λογική της είναι ακριβώς αυτό που χρειάζεται, παρόλα αυτά συνεχίζει να μην ανοίγει η σελίδα, ή να ανοίγει μισή. Καθάρισα όλα τα personal data/caches κλπ πριν ξαναπροσπαθήσω.

Οκ, στα 2 μηχανήματα που έχω δεν πετάει το αρχικό error με το cache:false οπότε θα ξαναπροσπαθήσω το βράδυ σε άλλα μηχανήματα να πετύχω κι αυτό το issue.

Σε win7 με τις 32bit εκδόσεις των explorer 8 και explorer 9 (το ίδιο ακριβώς version με του Βαγγέλη πιο πάνω), αναπαράγω και γω την συμπεριφορά που λέει ο Μιχάλης στο σημείο 6. Το έχει δοκιμάσει κάποιος άλλος;

Έκανα άλλες 2 δοκιμές, σε win7 με ie8. Το ένα dell inspiron 1525 σχετικά παλιότερης τεχνολογίας (3ετίας, core 2, 2gb ram) και σε ένα Sony Vaio με core i5 και 4 gb ram. Και τα 2 παρουσίαζαν πρόβλημα στο list view όπως περιγράφω και παραπάνω για τον ie8, κατά τα άλλα όμως δεν είχαν πρόβλημα.

Mike Muzurakis wrote:

Έκανα άλλες 2 δοκιμές, σε win7 με ie8. Το ένα dell inspiron 1525 σχετικά παλιότερης τεχνολογίας (3ετίας, core 2, 2gb ram) και σε ένα Sony Vaio με core i5 και 4 gb ram. Και τα 2 παρουσίαζαν πρόβλημα στο list view όπως περιγράφω και παραπάνω για τον ie8, κατά τα άλλα όμως δεν είχαν πρόβλημα.

ΟΚ, χρειάζεται να βρούμε τι διαφορετικό έχει το δικό μου σύστημα και το σάιτ κολλάει εντελώς με IE9.
Ο [cven] έχει στήσει 406ebc3bb7 από branch ui-0.3 στο http://62.217.120.67:8002. Με Opera μπαίνω κανονικά, με IE9 βγάζει μόνο το μισό παράθυρο, κρεμάει το σύμπαν, μέχρι που τον σκοτώνω.

Για να το προχωρήσω παραπάνω και να το λύσουμε, μπορείτε να επιβεβαιώσετε ότι το συγκεκριμένο σάιτ παίζει κανονικά σε εσάς;

Vangelis Koukis wrote:

Για να το προχωρήσω παραπάνω και να το λύσουμε, μπορείτε να επιβεβαιώσετε ότι το συγκεκριμένο σάιτ παίζει κανονικά σε εσάς;

Όχι. Στο συγκεκριμένο και ο δικός μου IE (version 9, win7) έχει πρόβλημα. Μόνο μία φορά έβγαλε την welcome screen, τις υπόλοιπες κολλάει. Δεν φταίει η welcome screen (τουλάχιστον όχι μόνο) αφού στο δικό μου instance τοπικά στο δίκτυο ο ΙΕ δεν έχει πρόβλημα με τη welcome screen. Έχει κάτι το ιδιαίτερο το setup του [cven] σε σχέση με ένα απλό development setup?

Στήνω κι εγώ ένα απομακρυσμένο setup για να δοκιμάζουμε και σε αυτό να δούμε τι διαφορετικό υπάρχει.

Mike Muzurakis wrote:

Vangelis Koukis wrote:

Για να το προχωρήσω παραπάνω και να το λύσουμε, μπορείτε να επιβεβαιώσετε ότι το συγκεκριμένο σάιτ παίζει κανονικά σε εσάς;

Όχι. Στο συγκεκριμένο και ο δικός μου IE (version 9, win7) έχει πρόβλημα. Μόνο μία φορά έβγαλε την welcome screen, τις υπόλοιπες κολλάει. Δεν φταίει η welcome screen (τουλάχιστον όχι μόνο) αφού στο δικό μου instance τοπικά στο δίκτυο ο ΙΕ δεν έχει πρόβλημα με τη welcome screen. Έχει κάτι το ιδιαίτερο το setup του [cven] σε σχέση με ένα απλό development setup?

Όχι, δεν έχει τίποτε, και δεν υπάρχει λόγος να χάνεις το χρόνο σου στήνοντας ένα δικό σου setup. Πρέπει να παίξει με το συγκεκριμένο.

Ο λόγος που κολλάει είναι απλός, και τον αναφέρω συχνά-πυκνά: η απομακρυσμένη πρόσβαση ξεσκεπάζει [προϋπάρχοντα] προβλήματα υποθέσεων που κάνει ο κώδικας για το πότε γίνεται το κάθε τι. Αν δεν γίνουν όλα ακριβώς όπως τα περιμένεις, σκάει. Races.

Ο κώδικας του interface λαμβάνεται κανονικά από τον IE; ναι. Το API απέναντι απαντάει ότι πρέπει; ελέγξτε το. Ε, πρέπει να παίξει.

Το ticket είναι λογικό ότι δεν μπορεί να κλείσει μέχρι να παίξει αυτό. Μάλιστα, για να γίνει σοβαρή δουλειά, δοκίμασε και ένα time.sleep(random.random()) μέσα στην @api_method, οπότε ίσως αρχίσουν να καταρρέουν κι άλλα πράγματα.

Ένα update όσο ψάχνουμε για λύση στο πρόβλημα.

Συμβαίνει μόνο στον django dev server. Όταν μπαίνει ο apache μπροστά λειτουργεί κανονικά ο ΙΕ.

Εδώ σερβίρεται από django:
http://6of2.unweb.me:8000/

κι εδώ από apache:
http://synnefo.unweb.me/

Ο django dev server είναι single threaded και ο ΙΕ τον lockarei λόγω ajax. Μέχρι να κλείσει ο ΙΕ, δεν απαντάει σε κανέναν.

να εξηγήσω λίγο καλύτερα και το πρόβλημα γιατί μάλλον δεν το εξήγησα καλά αρκετά καλά παραπάνω.

Τα requests του ajax είναι asynchronous. Όταν το UI στέλνει calls μαζεμένα στην αρχή (images, flavors, vms κτλ) ο browser στέλνει πολλά requests. Στην περίπτωση που ο server είναι single threaded (όπως ο django dev server), βρίσκεται μακριά (οπότε δεν απαντάει άμεσα) και ο browser επιτρέπει λίγα requests/domain (όπως ο ΙΕ 9), ο browser στέλνει τα calls αλλά μέχρι να απαντήσει ο server, έχει και τα 2 slots πια γεμάτα. Σαν αποτέλεσμα, ο server δεν προχωράει στο επόμενο call αφού δε μπορεί να απαντήσει σε αυτό που έχει τώρα. Οπότε ο server κολλάει (μέχρι να κλείσουμε τον ΙΕ οπότε ξεμπλοκάρει πια και πάει στα επόμενα) και ο ΙΕ ανάλογα σε τι έχει προλάβει να απαντήσει ο server εμφανίζει inconsistent συμπεριφορά. Μπορεί να δείξει όλο το UI, μπορεί να μη δείξει τίποτα, ή να δείξει τη μισή σελίδα και να κρασάρει.

Απαντάω τη συζήτηση και για τις δύο σημειώσεις.

Dimitris Moraitis wrote:

O Apache απλώς είναι ένας πλήρης web server. Το Django παρέχει έναν υποτυπώδη web server για να διευκολύνει το development, ο οποίος έχει περιορισμούς.

Έχεις απόλυτο δίκιο σε αυτό. Αυτοί οι περιορισμοί όμως δεν δικαιολογούν να μην παίζει καθόλου το σάιτ. Θέλω να πω, ακόμη δεν έχει δειχθεί επαρκώς γιατί μας ενοχλεί ότι ο runserver έχει μόνο ένα outstanding request; Ποιο είναι το πρόβλημα αν ο runserver ικανοποιεί το ένα request μετά το άλλο, γιατί αυτό κάνει το δικό μας σάιτ να σκάει; αν αυτό απαντηθεί επαρκώς, προφανώς δεν έχω πρόβλημα να το πάρω απόφαση και να πάμε παρακάτω.

Λέω όμως ότι αυτό, ο runserver είναι το σύμπτωμα, όχι το πρόβλημα. Το πρόβλημα είναι σε κάτι που κάνει η client-side Javascript. Θα ήθελα λοιπόν μια λεπτομερή απάντηση σε αυτό.

Οι browsers έχουν outstanding όσα requests είναι ρυθμισμένοι. Είναι αδιανόητο να εξαρτάται η συμπεριφορά του σάιτ από το πόσα requests επιτρέπονται ταυτόχρονα. Γιατί η "παραμικρή" καθυστέρηση να προκαλεί πρόβλημα; τι συμβαίνει όταν "γεμίσουν" τα δύο slots; γιατί κολλάει για πάντα; τίποτε από αυτά δεν είναι προφανές.

Γιατί όλα τα άλλα sites παίζουν κανονικά με IE7-8-9 χωρίς να ζητήσουν από τους χρήστες να πειράξουν τον αριθμό των slots, γιατί έχουν apache να απαντάει πολλά requests ταυτόχρονα;

Κανένα site δεν είναι deployed με τον web server του Django.

Έχεις απόλυτο δίκιο και σε αυτό. Αλλά λες ότι αν έβαζα τον ΙΕ να έχει μόνο ένα outstanding request, όλα αυτά τα sites θα σταματούσαν να έπαιζαν;

Κατ'αρχάς, όπως κι η ίδια η Microsoft λέει, τα δύο ταυτόχρονα requests είναι mandated από το HTTP/1.1, ασχέτως αν [για άλλους λόγους, σχετικούς με την επίδοση] οι browsers επιλέγουν να έχουν περισσότερα από τόσα outstanding requests: http://support.microsoft.com/kb/183110

Για να λυθούν τα προβλήματα με τον ΙΕ 9 και τον django server χρειάζεται κάποια συνολλικότερη αλλαγή στον τρόπο που γίνονται τα requests. Σε κάθε περίπτωση είναι θέμα deployment, σε production setup παίζει και τώρα σε όλους τους browsers.

Δεν μου είναι προφανές για πιο λόγο απαιτούνται από την υπάρχουσα σχεδίαση πάνω από 2 ταυτόχρονα requests. Μπορείτε να απαντήσετε ποια requests γίνονται ταυτόχρονα; γιατί δεν τελειώνει το ένα request πριν ξεκινήσει το επόμενο;

Γιατί να τελειώνει το ένα request πριν ξεκινήσει το επόμενο; Θα μπορούσε μεν να γίνει κάτι τέτοιο με τη χρήση μιας ουράς σαν workaround στο παραπάνω ζήτημα αλλά αυτό θα έχει σαν αποτέλεσμα το ui να είναι λιγότερο responsive, ο κώδικας να γίνει πιο πολύπλοκος, δυσανάγνωστος και error prone. Επίσης για να γίνει ένα τέτοιο refactoring θα χρειαστεί να ξοδέψουμε πολύ χρόνο και το μόνο που θα κερδίσουμε θα είναι να παρακάμψουμε το πρόβλημα που έχει ο IE9 με τον development web server του Django.

Το πρόβλημά μου δεν είναι πόσα requests γίνονται ταυτόχρονα. Μπορούν να γίνονται όσα θέλουμε ταυτόχρονα. Το θέμα είναι γιατί χρειάζεται να γίνονται πολλά μαζί ταυτόχρονα. Νομίζω ότι δεν έχει υπάρξει ξεκάθαρη απάντηση σε αυτό. Αυτό που θέλω να πω, είναι ότι αν είναι να γίνουν 20 requests, γιατί σπάει η εκτέλεση αν δεν γίνουν και τα 20 μαζί, αλλά πρέπει να γίνουν δύο-δύο;

Σε αυτό είναι απαραίτητο να δοθεί μια πειστική απάντηση, με ακριβές timeline των requests, για να είναι ξεκάθαρη και τεκμηριωμένη η λειτουργία του κώδικα.

αν καταλαβαίνω καλά, ο IE κάνει ένα request και ξεκινάει να το επεξεργάζεται ο runserver. Ε, αυτό δεν θα το τελειώσει κάποια στιγμή; Γιατί δεν τελειώνει, οπότε μετά να ξεκινήσει το επόμενο;

Μέχρι να γίνει αυτό ο IE9 τα τινάζει για δικούς του λόγους. Οι υπόλοιπες εκδόσεις του ΙΕ κ οι υπόλοιποι browsers δουλεύουν κανονικά και σε αυτή την περίπτωση.

Ποιοι είναι οι λόγοι που ο IE9 τα τινάζει; συγκεκριμένα. Με αντίστοιχα bugs από Microsoft.
Μήπως ο υπάρχον Javascript κώδικας βάζει εξαρτήσεις ανάμεσα στα requests, που δεν θα έπρεπε να υπάρχουν; αυτό ακούγεται πιθανός λόγος: Ενώ κάνω το request A, η Javascript απαιτεί να γίνει το request B ως εξάρτηση για να τελειώσει το Α (μη τεκμηριωμένη συμπεριφορά, είναι bug, εκτός αν υπάρξει πλήρης δικαιολόγησή της). Μόνο έτσι ίσως μπορεί να εξηγηθεί γιατί κολλάει το σύστημα.

Το ticket θέλει δουλειά ακόμη. Τι συμβαίνει, ποια είναι τα requests, και ποιες είναι οι εξαρτήσεις ανάμεσά τους; γιατί δεν μπορεί ο runserver να απαντήσει το ένα μετά το άλλο τα requests, single-threaded έστω, και να τελειώνει η υπόθεση;

Δεν είναι απλό ζήτημα του server που χρησιμοποιείται. Είναι ότι δεν έχουμε κατανόηση του πώς λειτουργεί το UI. Και δεν μπορούμε να φτιάξουμε το software που πάμε να φτιάξουμε, χωρίς πλήρη κατανόηση.

Έχουμε πλήρη κατανόηση πως λειτουργεί το UI. Το πρόβλημα συνδέεται άμεσα με την αρχιτεκτονική που επιλέχτηκε. Δεν υπήρχε κανένας λόγος να κάνει ο browser 1 request για τα images, 1 για τα flavors και άλλο 1 για τα vms με το καλημέρα. Όλα αυτά θα μπορούσαν να γίνουν σε ένα και μόνο request και ο client side κώδικας θα ήταν πολύ πιο απλός και να δεν θα αντιμετωπίζαμε αντίστοιχα ζητήματα. Αυτό ήταν 100% δική σας επιλογή για την οποία είχαμε προειδοποιήσει ότι μπορεί να οδηγήσει σε προβλήματα.

Πράγματι, η αρχιτεκτονική είναι δική μας επιλογή. Ωστόσο, ακόμη δεν έχει απαντηθεί ξεκάθαρα, γιατί δεν λειτουργεί όταν γίνονται τρία ανεξάρτητα requests. Ας ξεκινήσω εγώ λοιπόν μια υπόθεση: η Javascript θέλει να κάνει 3 requests "ταυτόχρονα". Τα δύο ξεκινάνε, το τρίτο μπλοκάρει. ΟΚ. Κανένα πρόβλημα. Ο runserver κάνει αρχικά το πρώτο, το τελειώνει. Μετά πιάνει το δεύτερο. Με το που τελειώσει το πρώτο, το τρίτο έχει ξεμπλοκαριστεί, γιατί ο IE θέλει πάντα 2 να είναι outstanding. Κάποια στιγμή ο runserver τελειώνει το δεύτερο, πιάνει το τρίτο. Τελειώνει και με αυτό. Όλα καλά.

Μπορείτε να απαντήσετε με σαφήνεια γιατί δε συμβαίνει αυτό;

Αυτό το ticket είναι η τέλεια ευκαιρία να το κάνουμε.

Αν πρέπει να κάνουμε κάτι παραπάνω στα πλαίσια αυτού του τίκετ πείτε μας τι ακριβώς είναι αυτό.

Πρέπει το site να παίξει με τον development server. Αν αυτό δεν είναι εφικτό, πρέπει να είναι επακριβώς τεκμηριωμένη η συμπεριφορά της Javascript που προκαλεί το πρόβλημα, και να δούμε αν αυτή είναι δικαιολογημένη. Χωρίς αυτό, δεχόμαστε στα τυφλά ότι κάτι δεν παίζει για κάποιο λόγο που δεν έχουμε καταλάβει.

Προφανώς ο σκοπός μου δεν είναι να σας προκαλέσω πρόβλημα. Είναι να έχουμε κατανόηση του κώδικα.
Γιατί όταν ένα απλό σάιτ φτάνει να έχει τέτοιες απαιτήσεις από τον server [αλλάξτε τον αριθμό των threads, ρυθμίστε περισσότερα outstanding requests, κάντε να απαντάει πιο γρήγορα], είναι σίγουρο ότι όταν αυξηθεί το φορτίο και μπει σε παραγωγή θα αρχίσουν να σκάνε τα race conditions το ένα μετά το άλλο.

Mike Muzurakis wrote:

να εξηγήσω λίγο καλύτερα και το πρόβλημα γιατί μάλλον δεν το εξήγησα καλά αρκετά καλά παραπάνω.

Τα requests του ajax είναι asynchronous.

Σύμφωνοι.

Όταν το UI στέλνει calls μαζεμένα στην αρχή (images, flavors, vms κτλ) ο browser στέλνει πολλά requests.

Φαντάζομαι αυτό ακριβέστερα μπορεί να ειπωθεί "η Javascript απαιτεί να φύγουν πολλά requests κι ο browser τα κάνει άνα N, ανάλογα με το πόσα επιτρέπει να είναι outstanding κάθε στιγμή".

Στην περίπτωση που ο server είναι single threaded (όπως ο django dev server), βρίσκεται μακριά (οπότε δεν απαντάει άμεσα) και ο browser επιτρέπει λίγα requests/domain (όπως ο ΙΕ 9), ο browser στέλνει τα calls αλλά μέχρι να απαντήσει ο server, έχει και τα 2 slots πια γεμάτα.

Συμφωνώ απόλυτα. Ο IE έχει στείλει δύο requests, σταματάει να στέλνει άλλα, και περιμένει απάντηση.

Σαν αποτέλεσμα, ο server δεν προχωράει στο επόμενο call αφού δε μπορεί να απαντήσει σε αυτό που έχει τώρα.

ΑΥΤΟ δεν το καταλαβαίνω. ΓΙΑΤΙ ο server δεν μπορεί να απαντήσει το ένα call μετά το άλλο; ΓΙΑΤΙ δεν μπορεί να απαντήσει σε αυτό που έχει τώρα; τι τον σταματάει; ποιο είναι το call που έχει τώρα; δεν το απάντησε; δεν θα το απαντήσει σε πεπερασμένο χρόνο; υπάρχει κάτι που τον κρατάει busy; περιμένει κάτι άλλο από τον client; ο client του έχει ζητήσει κάτι, κάποια στιγμή δεν θα του το απαντήσει να πάει παρακάτω;

Νομίζω εδώ χρειάζεται τουλάχιστον Wireshark logs που να απαντούν με ακρίβεια στην ερώτηση: γιατί ο runserver δεν τελειώνει με αυτό το request που έχει τώρα, για να πιάσει τα υπόλοιπα. Οπότε θα αδειάσουν τα slots που έχει ο IE.

Οπότε ο server κολλάει (μέχρι να κλείσουμε τον ΙΕ οπότε ξεμπλοκάρει πια και πάει στα επόμενα) και ο ΙΕ ανάλογα σε τι έχει προλάβει να απαντήσει ο server εμφανίζει inconsistent συμπεριφορά. Μπορεί να δείξει όλο το UI, μπορεί να μη δείξει τίποτα, ή να δείξει τη μισή σελίδα και να κρασάρει.

ΟΚ, καταλαβαίνω τι εννοείς. Η ερώτηση παραμένει: ΠΩΣ μπορεί ο IE να κρατήσει τον runserver κατειλημμένο, και γιατί;
Δεν του ζητάει κάτι; δεν έχει αυτό το κάτι; γιατί δεν πάνε παρακάτω τα πράγματα;

Το ticket δεν μπορεί να κλείσει χωρίς ξεκάθαρη απάντηση στα ερωτήματα που τίθενται παραπάνω.
Ακριβές timeline των requests (wireshark?) και των εξαρτήσεων ανάμεσά τους.
Ακριβής συμπεριφορά της Javascript και του IE που προκαλεί το πρόβλημα, ει δυνατόν με authoritative links.

Vangelis Koukis wrote:

ΟΚ, καταλαβαίνω τι εννοείς. Η ερώτηση παραμένει: ΠΩΣ μπορεί ο IE να κρατήσει τον runserver κατειλημμένο, και γιατί;
Δεν του ζητάει κάτι; δεν έχει αυτό το κάτι; γιατί δεν πάνε παρακάτω τα πράγματα;

Το ticket δεν μπορεί να κλείσει χωρίς ξεκάθαρη απάντηση στα ερωτήματα που τίθενται παραπάνω.
Ακριβές timeline των requests (wireshark?) και των εξαρτήσεων ανάμεσά τους.
Ακριβής συμπεριφορά της Javascript και του IE που προκαλεί το πρόβλημα, ει δυνατόν με authoritative links.

Απλά ήθελα να συμπληρώσω την εκτίμησή μου για την ακριβή διαδικασία του πώς δημιουργείται το πρόβλημα (καλό θα ήταν να γίνει περισσότερη έρευνα αν θέλουμε να είμαστε 100% σίγουροι γιατί ο ΙΕ κρασάρει, αλλά μεχρι στιγμής ως εκεί έχω φτάσει ερευνώντας τη συμπεριφορά και χρησιμοποιώντας τον fiddler για να δω το network traffic) : O IE στέλνει μαζεμένα κάποια asynchronous requests. Ο django server ξεκινά να τα επιστρέφει ένα-ένα όπως τα επεξεργάζεται μιας και είναι single threaded. Όμως αν ο IE στείλει 2 requests πριν ο django server τελειώσει αυτό που κάνει, τα slots γεμίζουν αφού ο server δεν απαντά ακόμα. Ο django server προσπαθεί να επικοινωνήσει με τον ΙΕ μόλις τελειώσει αυτό που κάνει για να το στείλει, αλλά ο ΙΕ έχει ήδη πλέον γεμάτα τα slots. Οπότε ο server δε μπορεί να απαντήσει, ο IE μένει με τα slots γεμάτα και έχουμε deadlock. Στην περίπτωση του apache, ο server συνεχίζει να αναλαμβάνει τα asynchronous requests του ΙΕ, τα slots αδειάζουν και οι απαντήσεις έρχονται κανονικά από το server οπότε δε δημιουργείται πρόβλημα.

Τα παραπάνω ενισχύονται από το γεγονός πως αν σηκώσει κανείς τον fiddler για να σνιφάρει την κίνηση, το πρόβλημα εξαφανίζεται. Ο fiddler παρεμβάλεται ανάμεσα στον single threaded server και στα 2 slots του IE και λύνει το deadlock. To ακριβές timeline των requests φαίνεται στον fiddler αλλά δεν βοηθάει και πολύ. Το πότε θα γίνει το deadlock εξαρτάται από τo το δίκτυο και το server response time γι αυτό και γίνεται σε διαφορετικά σημεία (μερικές φορές και καθόλου).

Mike Muzurakis wrote:

Απλά ήθελα να συμπληρώσω την εκτίμησή μου για την ακριβή διαδικασία του πώς δημιουργείται το πρόβλημα (καλό θα ήταν να γίνει περισσότερη έρευνα αν θέλουμε να είμαστε 100% σίγουροι γιατί ο ΙΕ κρασάρει, αλλά μεχρι στιγμής ως εκεί έχω φτάσει ερευνώντας τη συμπεριφορά και χρησιμοποιώντας τον fiddler για να δω το network traffic) : O IE στέλνει μαζεμένα κάποια asynchronous requests. Ο django server ξεκινά να τα επιστρέφει ένα-ένα όπως τα επεξεργάζεται μιας και είναι single threaded. Όμως αν ο IE στείλει 2 requests πριν ο django server τελειώσει αυτό που κάνει, τα slots γεμίζουν αφού ο server δεν απαντά ακόμα.

Δεν είμαι σίγουρος ότι συμβαίνει αυτό...
Τα slots δεν θα έπρεπε να τον αποτρέπουν να λάβει μια απάντηση...

Βρήκα όμως το εξής:

http://stackoverflow.com/questions/3593330/http-header-connection-close-not-sent-by-ie

Ο django server προσπαθεί να επικοινωνήσει με τον ΙΕ μόλις τελειώσει αυτό που κάνει για να το στείλει, αλλά ο ΙΕ έχει ήδη πλέον γεμάτα τα slots. Οπότε ο server δε μπορεί να απαντήσει, ο IE μένει με τα slots γεμάτα και έχουμε deadlock.

Αυτό δεν βγάζει νόημα. Θέλω να πω, αν ο IE έχει μια ανοιχτή σύνδεση, μπορεί να πάρει απάντηση εκεί.
Αυτό που μου ήρθε διαβάζοντας το παραπάνω κείμενο είναι ένα τέτοιο σενάριο:

Ο IE κρατάει ανοιχτή τη σύνδεση, όταν φορτώνει τη σελίδα [δεν έχω δει wireshark logs].
Το κάνει γιατί κάνει HTTP/1.1 persistent connections.
ΜΕΤΑ, ενώ η σελίδα έχει φορτώσει, η Javascript παράγει νέα requests, με AJAX, για τα οποία ο IE ανοίγει μια νέα σύνδεση.
Αυτή η σύνδεση δεν μπορεί να εξυπηρετηθεί ποτέ.

Οπότε, η απάντηση στο ερώτημα που είχα κάνει παραπάνω, "με ποιον τρόπο ο IE αποτρέπει τον development server να εξυπηρετήσει το request και να πάει παρακάτω" είναι "με το να κρατάει ανοιχτή τη σύνδεση".

Αυτό θα έβγαζε νόημα. Σε αυτό το σενάριο, δεν παίζει ρόλο πόσα outstanding requests έχει ο IE, και αν είναι 2 ή 3 ή 5, όπως ειπώθηκε στην αρχή. Το μόνο που παίζει ρόλο είναι ότι κρατάει ανοιχτή την αρχική σύνδεση, μήπως ζητήσει κι άλλα πράγματα, και μετά ζητάει με AJAX, τα οποία δεν μπορούν να εξυπηρετηθούν.

Έκανα μια βιαστική δοκιμή, πειράζοντας κλειδιά κάτω από το:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
σύμφωνα με το
http://support.microsoft.com/kb/813827

ώστε ο IE να κλείνει σε 2 sec τις συνδέσεις του.
Τότε, η σελίδα φορτώνει σχεδόν πάντα με τον development server, αλλά βγάζει "no images found", ενώ υπάρχουν images.

Στην περίπτωση του apache, ο server συνεχίζει να αναλαμβάνει τα asynchronous requests του ΙΕ, τα slots αδειάζουν και οι απαντήσεις έρχονται κανονικά από το server οπότε δε δημιουργείται πρόβλημα.

Αυτό δεν ισχύει, σύμφωνα με το παραπάνω σενάριο. Ο apache απλώς έχει τη δυνατότητα να δεχτεί νέα σύνδεση από τον IE, ενώ ο IE κρατάει κατειλημμένη την παλιά. Προσπάθησα να βρω κάποιο setting ο runserver να κλείνει το connection (α λα KeepAliveTimeout του apache) αλλά δεν βρήκα.

Τα παραπάνω ενισχύονται από το γεγονός πως αν σηκώσει κανείς τον fiddler για να σνιφάρει την κίνηση, το πρόβλημα εξαφανίζεται. Ο fiddler παρεμβάλεται ανάμεσα στον single threaded server και στα 2 slots του IE και λύνει το deadlock. To ακριβές timeline των requests φαίνεται στον fiddler αλλά δεν βοηθάει και πολύ. Το πότε θα γίνει το deadlock εξαρτάται από τo το δίκτυο και το server response time γι αυτό και γίνεται σε διαφορετικά σημεία (μερικές φορές και καθόλου).

Δεν ξέρω τι κάνει o fiddler. Είναι κάποιου είδους HTTP proxy; τότε απλώς αυτός κάνει μία σύνδεση τη φορά με τον runserver, και σταματούν σε αυτόν οι πολλαπλές συνδέσεις του IE.

Ένα σενάριο σαν αυτό που περιγράφω παραπάνω μου φαίνεται λογικό. Ιδανικά θα έπρεπε να επιβεβαιωθεί με το wireshark.
Ας μην το κουράζουμε άλλο αυτό το ticket, ας συνεχίσουμε αν μένει κάτι στα υπόλοιπα και αν υπάρξει πρόβλημα, ανοίγει νέο.