Haciendo pruebas con Sipesca, para intentar lanzar el sincronizador nuevamente con las nuevas URLs de peticiones de la APIRest, que son la misma, pero «http» en lugar de «https», me doy cuenta de que no «existen» aún los valores de los nodos antiguos.
Me parece que voy a decidir «lanzarlo» por si sincronizase algún valor, pero dejarlo latente que aún eso no funciona.
Cómo estoy cansado de redirigir el tráfico y tener que lanzarlo a mano, me he creado un script llamado lanzar.sh que básicamente tiene lo siguiente:
[code language=»bash»]nohup java -jar SiMa > /etc/null [/code]
Además, así le echo un ojo a como nos pasamos de la quota de fusion tables, que siempre es curioso ver los gráficos desbordarse 😛
Um, cosa rara. El sincronizador está fallando en la clase del calendario, dando este error:
[code language=»bash»]Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: -2
at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:454)
at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2333)
at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2248)
at java.util.Calendar.setTimeInMillis(Calendar.java:1140)
at java.util.Calendar.setTime(Calendar.java:1106)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:955)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:948)
at java.text.DateFormat.format(DateFormat.java:336)
at ActualizadorLocal.ActualizadorDBLocal.actualizarDispositivos(ActualizadorDBLocal.java:141)
at ActualizadorLocal.ActualizadorDBLocal.actualizaDesdeFecha(ActualizadorDBLocal.java:338)
at ActualizadorLocal.ActualizadorDBLocal.run(ActualizadorDBLocal.java:241)[/code]
El error se indica en el cálculo de la etiqueta del fichero de log, por lo que no es un elemento crítico, pero no por ello voy a dejar de ver de que se trata.
Acoto la línea dividiéndola en varias partes, para ver cual falla. Apuesto que es en el startDate:
[code language=»java»] String label = Debug.sdf.format(startDate);
label += " a ";
label += Debug.sdf.format(endDate);
label += " para ";
label += clientNo.getNodo(i) + ".";[/code]
Parece que falla en el endDate, vaya, mi apuesta es erronea. A pesar de que endDate se escribe en una zona de exclusión mutua, y la lectura se hace con un syncronized, así que no creo que sea por un problema de pisamiento.
¡Magia! Si pongo un system.err.print() antes, no da problema. Es sólo un problema estético, pero oye, me está mosqueando xD
Cómo es un problema de visualización y realmente me da igual el formato en el que se ve en los ficheros de logs (que si todo va bien, no hay ni que mirarlos), voy a omitir la conversión a formato «gregoriano» y lo dejo expresado en timestamp.
Se me ocurre una mejora, comprobar si la caché de nuevos dispositivos a insertar está vacía, preprocesarlo para no llegara a generar la tarea en la cola (ahora, la base de datos tiene que darse cuenta de que no hay ningún dispositivo nuevo que insertar), ahorramos algo de tiempo en la manipulación de hebras y esas cosas.
Y la APIRest sigue dando «por saquito», mira que me he encontrado:
[code language=»xml»]
may 06, 2014 5:58:21 PM ActualizadorLocal.Clientes.ClienteDispositivos procesarDatos
Advertencia: Fallo en el procesamiento de los datos {"dispositivos":<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<title>City Analytics</title>
<link rel="stylesheet" href="./css/index.css" type="text/css" media="screen" charset="utf-8" />
</head>
<body id="cityanalytics">
<div id="page">
<form action="j_security_check;jsessionid=29827F13B7247301A57BB27F5910BD0B" method="post">
<fieldset>
<p><input type="text" name="j_username" placeholder="Usuario" /></p>
<p><input type="password" name="j_password" placeholder="Contraseña" /></p>
<p><button type="submit" value="Entrar">Entrar</button></p>
</fieldset>
</form>
</div>
<div id="footer">
<div id="footer_content">
<p>
<a href="http://intelify.net/">Intelify</a></strong><br />
Calle Prolongación Cursillos, 38. 14012 Córdoba.<br />
Teléfono: 957 760 033
</p>
</div>
</div>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src=’" + gaJsHost + "google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-12298654-1");
pageTracker._trackPageview();
} catch(err) {}
</script>
<!– index –>
</body>
</html>
HTTP/1.1 204 No Content
Server: Apache-Coyote/1.1
Content-Type: application/json
Date: Tue, 06 May 2014 15:55:13 GMT
}
http://cityanalytics.net/restapi/rawdataservice/1388397445798/dispositivos?user=pcastillo&pass=pcastillo&start=1386921600000&end=1387008000000&inc=true
Unexpected character (<) at position 16.
at org.json.simple.parser.Yylex.yylex(Yylex.java:610)
at org.json.simple.parser.JSONParser.nextToken(JSONParser.java:269)
at org.json.simple.parser.JSONParser.parse(JSONParser.java:118)
at org.json.simple.parser.JSONParser.parse(JSONParser.java:81)
at org.json.simple.parser.JSONParser.parse(JSONParser.java:75)
at ActualizadorLocal.Clientes.ClienteDispositivos.procesarDatos(ClienteDispositivos.java:224)
at ActualizadorLocal.ActualizadorDBLocal.actualizarDispositivos(ActualizadorDBLocal.java:166)
at ActualizadorLocal.ActualizadorDBLocal.actualizaDesdeFecha(ActualizadorDBLocal.java:349)
at ActualizadorLocal.ActualizadorDBLocal.run(ActualizadorDBLocal.java:252)
[/code]
Que bonito, ¡la APIRest me devuelve el formulario de la web de login! Con un par de pelotas xD
Voy a dejarlo por hoy, que me voy a poner con otra cosa.