Posts by paul

    Nach ein wenig Frickelarbeit ist mir gelungen STARFACE auf einem Sheeva Plug mit einem ARM Prozessor unter Ubuntu 9.04 laufen zu lassen.
    Softwarekomponente:
    OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu10)
    Tomcat 5.5
    Asterisk 1.4.36
    PostgreSQL 8.3.11


    Die Weboberflaeche und Telefonie funktionieren (nur Grundfunktionalitaeten getestet). Nur ein kleines Problemchen habe ich. Wegen eines Bugs in JIT Compiler der OpenJDK fuer ARM5 Plattform ist es unmoeglich Starface mit JIT zu starten, es geht nur in interpreter Modus was erwartungsgemaess nicht die optimale Performance liefert:



    Das Problem liegt in der Verwendug der JMX Technologie. Waere es moeglich JMX irgendiwe per Konfiguration zu unterbinden? Sonst wird mit eingeschatetem JIT-Compiler folgende Exception geworfen und Webapp startet dann nicht:



    Wenn dass mit JIT klappt koennte man STARFACE als supersparsame Kleinstinstallation laufen lassen: Energieverbrauch unter 5 Watt und eine SD-Card fuer Root-Partition. Das waere echt GREEEEEN ;-D



    Gruess,
    Paul

    Hi,


    um den richtigen Namen, bzw Rufnummer, anzuzeigen muss man nur entsrpechenden Eintrag im SNOM-Adressbuch machen. Bei frueheren SNOM Modellen (z.B. 360) wurde das gleich bei der Funktionstastenuebetragung von SF erledigt. Wieso das jetzt mit SNOM 370 nicht geht weiss ich momentan nicht. Wahrscheinlich ist es ein Fehler.


    Gruesse

    Hallo slu,


    die Datenuebertragung erfolgt per HTTPS mit ganz normalem HTTP POST-Request. Dazu muss sich Starface gar nicht bei dem Server authentifizieren. Die Serveridentitaet wird dagegen mit einem von uns signiertem SSL-Zertifikat auf Clientseite geprueft. Datenuebertragung selbst wird mit AES128 verschluesselt. Fuer nicht Techies: gleiches Verfahren wie bei Internet-Banking. Von Extern kann man auf die uebermittelte Daten gar nicht zugreifen (kein WebDAV). Daten koennen nur rein gehen, niemals raus. Die verschickte Logs bleiben nicht mal auf dem Webserver liegen, sondern werden sofort intern an den Support weitergeleitet.


    Gruesse
    Paul

    Hallo,


    mit IP-Adressen in XML manuell einzutragen ist es leider nicht getan. Der Anlagenverund ist auschliesslich darauf ausgelegt, dass die Anlagen direkt erreichbar sind: ohne NAT dazwischen. Mit entsprechend eingerichtetem Port-Forwarding waere es villeicht moglich Anlagen uber NAT zu verbinden. Das haben wir aber weder getestet oder ausprobiert. Allein aus Sicherheitsgruenden rate ich ausdruecklich ab Anlagen ueber oeffentlichen Internet zu koppeln. Fuer Anlagenverbund ist ein VPN zwischen den Standorten vorausgesetzt.


    Gruesse,
    Paul

    Hi slu,


    HttpGet liefert ein Stream Objekt zurueck und keinen Text. Fuer deinen Zweck waere HttpGetValue Funktion die bessere Wahl, weil die direkt ein Text-Objekt zuruckgibt. Mit HttpGetValue Funktion kann kann man sogar einfaches Pattern-Matching betreiben um z.B. aus einer Webseite benoetigten Abschnitt zu extrahieren.


    Gruesse,
    Paul

    Hi,


    kannst Du mir bitte die PDF Datei mit der Tastenbeschriftung und die Snoms HTML-Seite mit der Tastenbelegung (http://<telefon-ip>/fkeys.htm) an *geloescht* schicken? Intern koennen wir den Fehler nicht nachvollziehen deswegen moechte ich direkt schauen welche Daten in deinem Fall zum Fehler fuehren.



    Gruesse


    Paul

    Hat nach dem Update Jabber-Messaging funktioniert oder nicht? Nur das ist wichtig. Die Logausgaben kann man ignorieren: die ersten 2 Ausschnitte sagen nur dass Openfire versucht selbst Tabellen anzulegen die schon existieren (vom Installationsscript angelegt). Die letzten beiden Ausschnitte haben gar nichts mit Openfire zu tun.


    Gruesse

    Mit Googlemail wird es so oder so nicht gehen auch nicht mit anderem Port. Googlemail erlaubt nur verschluesselte Verbindungen mit SSL/TLS und Starface kann zur Zeit nur unverschluesselten SMTP.

    Hallo,
    die Tomcat Speicherreservierung unter OpenVZ muss man leider per Hand einstellen und nicht auf automatische Zuweisung verlassen. Etwa nach der Formel: (Gesamt_RAM / Anzahl_Instanzen) * 0,75. Mindestens 128MB muss es aber sein.

    Wir haben das Problem lokalisiert. Unter bestimmten Umstaenden schickt Watchdog zuviele Ping-Pakete zu Asterisk sodass CPU-Load bei Watchdog und Asterisk Prozessen stark ansteigt.


    Als Hotfix kann man die Datei /var/lib/watchdog/watchdog.jar durch gefixte watchdog.zip Version direkt ersetzen und 'service watchdog restart' aufrufen.


    Gefixte Watchdog wird auch in dem naechsten Bugfix-Release dabei sein.

    Tomcat reserviert fuer sich allein 75% des gesamten RAMs ohne andere OpenVZ Instanzen zu beruecksichtigen. In der 'top' Ausgabe sieht man, dass freie Speicher = 0 ist. Es bleibt nichts weder fuer Cache noch fuer IO-Buffers ueberig. Das allein fuer sich ist schon ein schwerer Fehler. Ich wuerde auf jeden Fall empfehlen /etc/init.d/tomcat5 Script anzupassen um den Speicherverbrauch zu reduzieren und dann Tomcat/System restarten.


    In der Version 3.5 von /etc/init.d/tomcat5 steht folgendes:


    Code
    JAVA_OPTS=$(free | grep "Mem" | awk '{CONVFMT = "%.0f"; tomcatmem= ($2-267890)/1024; if (tomcatmem < 128) tomcatmem=128; if (tomcatmem > 1
    024) tomcatmem=1024; print "-Xmx" tomcatmem "M  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/tomcat-jmv-dump.hprof -XX:PermSize=6
    4M -XX:MaxPermSize=128M -Dderby.storage.pageCacheSize=200"}')


    das kann man etwa so abaendern:


    Code
    JAVA_OPTS="-Xmx128M  -XX:PermSize=64M -XX:MaxPermSize=128M -Dderby.storage.pageCacheSize=200"


    Die Option -Xmx128M reserviert fuer Tomcat in diesem Fall 128MB RAM. Dies ist die unterste Grenze und sollte je nach Auslastung ggf erhoeht werden.