Encuesta larga congela el navegador y bloquea otra solicitud de ajax

Question

Estoy tratando de implementar una larga encuesta en mi Spring-MVC Web App pero congela mi navegador y otras solicitudes después de que 4-5 continúen las solicitudes de AJAX. No tengo idea de qué sucede aquí es mi código relevante .

El método controlador: (el lado del servidor): -

@Asynchronous 
    @RequestMapping("/notify") 
    public @ResponseBody 
    Events notifyEvent(HttpServletRequest request) { 
     Events events = null; 
     try { 
      events = (Events) request.getSession(false).getServletContext().getAttribute("events"); 
      System.out.println("Request Came from" + ((com.hcdc.coedp.safe.domain.User) request.getSession(false).getAttribute(Constants.KEY_LOGGED_IN_USER)).getLoginId()); 
      if (!events.getTypeOfEvents().isEmpty()) { 
       System.out.println("Removing older entries"); 
       events.getTypeOfEvents().clear(); 
      } 
      while (!events.isHappend()) { 
       //Waiting for event to happen. 
      } 
      events = Events.getInstance(); 
      events.setHappend(false); 
      request.getSession(false).getServletContext().setAttribute("events", events); 

     }catch (Exception e) { 
      e.printStackTrace(); 
     } 
     return events; 
    } 

El script-sondeo de largo (lado del cliente): -

$(document).ready(function() { 
        $.ajaxSetup({ 
         async:true//set a global ajax requests as asynchronus 
        }); 
        alert('Handler for .onload() called.'); 
        waitForMsg(); 

       }); 
       function waitForMsg(){ 

        xhr= $.ajax({ 
         type: "POST", 
         url: '<%=request.getContextPath()%>/notification/notify', 

         async: true, /* If set to non-async, browser shows page as "Loading.."*/ 
         cache: false, 
         timeout:50000, /* Timeout in ms */ 
         global:false, 
         success: function(data){ /* called when request to notifier completes */ 
          /* Doing smthing with response **/ 
          setTimeout(
          waitForMsg, /* Request next message */ 
          1000 /* ..after 1 seconds */ 
         ); 
         }, 
         error: function(XMLHttpRequest, textStatus, errorThrown){ 
          addmsg("error", textStatus + " (" + errorThrown + ")"); 
          setTimeout(
          waitForMsg, /* Try again after.. */ 
          15000); /* milliseconds (15seconds) */ 
         } 
        }); 
       }; 

UPDATE:

function updateFeed(event, data) { 
       var f=eval(data); 
       alert(f.typeOfEvents.length); 
      } 

      function catchAll(event, data, type) { 
       console.log(data); 
       alert("error"); 
       console.log(type); 
      } 

      $.comet.connect('<%=request.getContextPath()%>/notification/notify'); 
      $(document).bind('feed.comet', updateFeed); 
      $(document).bind('.comet', catchAll); 

Ningún cuadro de alerta aparece .. :(

Answer 1

Parece que tiene un bucle de tiempo vacío en el código de su navegador ... esta es una forma muy intensiva de esperar un evento.

Si no ocurre ningún evento, el cliente cancelará la solicitud después del tiempo de espera deseado de 50 segundos. Pero no estoy seguro si el hilo del servidor también se elimina, o si se "apaga" para siempre (a menos que haya un evento). La siguiente solicitud iniciará una segunda cadena de servidor que también se cuelga en el ciclo while. Tal vez la cantidad de ciclos while vacíos es excesiva para el servidor, por lo que deja de aceptar más solicitudes. Entonces, después de algunas solicitudes (que cada una desencadenó un hilo de servidor interminable) el cliente espera por siempre una nueva solicitud ... porque no puede ser manejada por el servidor.

ps: el éxito que ha comentado que esperar de 1 segundo, pero establece el tiempo de espera a 10000 (10 segundos)

Answer 2

Me he encontrado con un problema similar, mi navegador se vio afectado de alguna manera con las solicitudes AJAX. Sugerencia: en su lugar, usando waitForMsg() directamente, intente setTimeout ("waitForMsg()", 10).

Answer 3

FYI, aquí es un proyecto que podría ayudarle a: https://github.com/SeanOC/jquery.comet

En general, me gustaría buscar las API de JavaScript de cometas que pueden apoyar los zócalos web si está disponible en cliente/servidor con repliegue elegante de sondeo largo. La API debe manejar todos los detalles sangrientos, lo que le permite centrarse en la aplicación.

Aquí hay un enlace a un viejo artículo dojo sobre el tema: http://dojotoolkit.org/features/1.6/dojo-websocket

Buena suerte.

Answer 4

Puede ser esta:

 xhr= $.ajax({ (...) 

en su función waitForMsg.

Trate

var xhr = (...) 

Puede ser que está declarando xhr en el objeto global, por lo que es imposible responder a dos solicitudes diferentes.

Answer 5

Usted puede tratar de reescribir el comportamiento usando jQuery diferida:

function setShortTimeout() { 
    setTimeout(waitForMsg, 1000); 
} 

function setLongTimeout() { 
    setTimeout(waitForMsg, 15000); 
} 

$(document).ready(function() { 
       $.ajaxSetup({ 
        async:true//set a global ajax requests as asynchronus 
       }); 
       alert('Handler for .onload() called.'); 
       $.when(waitForMsg()) 
        .done(successHandler, setShortTimeout) 
        .fail(errorHandler, setLongTimeout); 

      }); 

      function waitForMsg(){ 
       return $.ajax({ 
        type: "POST", 
        url: '<%=request.getContextPath()%>/notification/notify', 
        async: true, /* If set to non-async, browser shows page as "Loading.."*/ 
        cache: false, 
        timeout:50000, /* Timeout in ms */ 
        global:false 
       }); 
      }; 

errorHandler y successHandler será su éxito: y de error: devoluciones de llamada, que he omitido para mayor claridad, con su parte setTimeout eliminado (ya que es ahora forma parte de las devoluciones de llamada deferred.done() y .fail()).

Avísame si funciona.

Answer 6

Soy un desarrollador PHP pero conocí su problema y podría ser el mismo comportamiento. Así que te doy mis 2 centavos y espero que te ayude.

La línea que me hace sospechar un problema es:

events = (Events) request.getSession(false).getServletContext().getAttribute("events"); 

En PHP, las sesiones se almacenan en archivos, y si somos largo de votación en un script php mientras que la sesión está abierta, nos encontramos un problema race condition.

El principio es muy simple:

1. Cuando una solicitud abre la sesión, archivo está bloqueado hasta que la sesión se cierra .
2. Si llegan otras solicitudes al servidor, se bloquearán hasta que se libere la sesión de la solicitud anterior.

En caso de una larga encuesta, si la sesión se abre y no se cierra justo después de obtener información (al menos, justo antes de esperar eventos), todas las solicitudes están bloqueadas, no se puede ir a ninguna otra parte el sitio web si usa sesiones en otras páginas. Incluso si abre una pestaña nueva, porque para un navegador solo hay una sesión, está bloqueado.

Answer 7

parece que ha experimentado bloquear el archivo de sesión

Para PHP

Uso session_write_close() cuando no se necesita valor de sesión