Cachewolf Java Version hängt sich auf

[skalar]

Hallo,

während dem updaten von ca. 3820 Caches hängt sich das Programm nach dem Abarbeiten von ca. 2800 Caches mit folgender Fehlermeldung auf:

cachewolf$ java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOfRange(Arrays.java:3221)
	at java.lang.String.<init>(String.java:233)
	at ewe.util.CharArray.toString(CharArray.java)
	at CacheWolf.imp.SpiderGC.fetchText(Unknown Source)
java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOfRange(Arrays.java:3221)
	at java.lang.String.<init>(String.java:233)
	at ewe.util.CharArray.toString(CharArray.java)
	at CacheWolf.imp.SpiderGC.fetchText(Unknown Source)
	at CacheWolf.imp.SpiderGC.getCacheByWaypointName(Unknown Source)
	at CacheWolf.imp.SpiderGC.downloadCaches(Unknown Source)
	at CacheWolf.imp.SpiderGC.doIt(Unknown Source)
	at CacheWolf.imp.SpiderGC.doIt(Unknown Source)
	at CacheWolf.MainMenu.onEvent(Unknown Source)
	at ewe.ui.Control.postEvent(Control.java)
	at ewe.ui.MenuState.onEvent(MenuState.java)
	at ewe.ui.Control.sendToListeners(Control.java)
	at ewe.ui.Control.postEvent(Control.java)
	at ewe.ui.Menu.postEvent(Menu.java)
	at ewe.ui.Menu.onEvent(Menu.java)
	at ewe.ui.Control.sendToListeners(Control.java)
	at ewe.ui.Control.postEvent(Control.java)
	at ewe.ui.Menu.postEvent(Menu.java)
	at ewe.ui.Control.notifyAction(Control.java)
	at ewe.ui.Menu.penReleased(Menu.java)
	at ewe.ui.Control.penClicked(Control.java)
	at ewe.ui.Control.onPenEvent(Control.java)
	at ewe.ui.Menu.onPenEvent(Menu.java)
	at ewe.ui.Control.onEvent(Control.java)
	at ewe.ui.Menu.onEvent(Menu.java)
	at ewe.ui.Control.postEvent(Control.java)
	at ewe.ui.Menu.postEvent(Menu.java)
	at ewe.ui.Window.doPostEvent(Window.java)
	at ewe.ui.Window$windowThread.run(Window.java)
	at ewe.sys.mThread.run(mThread.java)
	at ewe.sys.Coroutine.run(Coroutine.java)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:75)
	at java.awt.image.Raster.createPackedRaster(Raster.java:470)
	at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1032)
	at java.awt.image.BufferedImage.<init>(BufferedImage.java:338)
	at ewe.fx.Image.newBufferedImage(Image.java)
	at ewe.fx.Image.newBufferedImage(Image.java)
	at ewe.fx.Image.create(Image.java)
	at ewe.fx.Image.<init>(Image.java)
	at ewe.fx.Image.<init>(Image.java)
	at ewe.ui.Control.getControlBuffer(Control.java)
	at ewe.ui.Control.repaintNow(Control.java)
	at ewe.ui.Window._doPaint(Window.java)
	at ewe.applet.WinCanvas.addToQueue(WinCanvas.java:90)
	at ewe.applet.WinCanvas.paint(WinCanvas.java:639)
	at sun.awt.RepaintArea.paintComponent(RepaintArea.java:264)
	at sun.awt.X11.XRepaintArea.paintComponent(XRepaintArea.java:73)
	at sun.awt.RepaintArea.paint(RepaintArea.java:240)
	at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:712)
	at java.awt.Component.dispatchEventImpl(Component.java:4640)
	at java.awt.Container.dispatchEventImpl(Container.java:2163)
	at java.awt.Component.dispatchEvent(Component.java:4390)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:649)
	at java.awt.EventQueue.access$000(EventQueue.java:96)
	at java.awt.EventQueue$1.run(EventQueue.java:608)
	at java.awt.EventQueue$1.run(EventQueue.java:606)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:116)
	at java.awt.EventQueue$2.run(EventQueue.java:622)
	at java.awt.EventQueue$2.run(EventQueue.java:620)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:105)

Zum Rechner:
Quad Core Phenom II X4 965 à 3,4
16 GB RAM
1,5 TB frei HDD
Ubuntu Linux 10.04 LTE
CW 1.2.2956

Gibt es eines bekannte Obergrenze für die Java Applikation? Oder weiß jemand eine Lösung für diese Problem?

Danke & Gruß

Neo

 

[MiK]

CW funktioniert ganz gut mit ein paar hundert Caches im Profil. Mehr habe ich nie getestet.

Zum Thema, was ich davon halte auf einen Schlag mehrere 1000 Caches aktualisieren zu wollen, sag ich meine Meinung besser nicht.

 

[Nojan]

...während dem updaten von ca. 3820 Caches...

Solche Profilgrößen im Cachewolf sind absoluter Quatsch!
Und Du bist damit auf dem besten Wege zum "banned Member", wenn Du die alle auf einmal aktualisieren willst.
Gruß,
Nojan

 

[SammysHP]

Irgendwie liegt mir das Wort "Troll" auf der Zunge.

Aber dennoch: Es ist ein Bug in Cachewolf, wenn der Speicher nicht mehr freigegeben wird.

 

[Geo-Johnny]

...während dem updaten von ca. 3820 Caches...

Solche Profilgrößen im Cachewolf sind absoluter Quatsch!

Ganz meine Meinung.

 

[Inder]

Aber bei mir zeigt sich das gleiche Problem, wenn ich ein etwa gleich großes Profil (aus PQs erstellt) zu einer KML exportieren will oder über ein Template auf das GPS bringe. Deswegen musste ich das Profil in zwei Einzelteile zerlegen und muss nun beide Exporte doppelt ausführen. Danach werden die Exportdateien erst mal wieder zusammengefügt und dann weiter verarbeitet. Mache ich schon lange so und kann damit leben. Aber es wäre auch für mich eine gewaltige Erleichterung und Zeitersparnis, wenn die Speicherverwaltung mal von dem Bug befreit würde und man auch große Profile in einem Rutsch exportieren könnte. Ein großes Profil ist nun mal schneller gepflegt als mehrere kleine.

Möglicherweise macht es keinen Sinn, so viele Caches zu aktualisieren. Aber ich kann es nicht beurteilen, ob Neo schlicht nicht über die Konsequenzen nachgedacht hat oder einen besonderen Grund dafür hat. Wenn er dafür künftig ein Login-Captcha kassiert, dann ist es sein Pech - nicht unseres. Ich finde Neos Anfrage durchaus berechtigt und verstehe nicht, warum solche oder ähnliche Posts immer zu Flames führen müssen. Schön, wenn jemand mit kleinen Profilen zurecht kommt. Aber es gibt nun mal Anwender, die einen anderen Workflow (und oft auch ihre Gründe dafür) haben. Wenn dann so jemand auf einen offensichtlichen Bug stößt und diesen postet, dann sollte das respektiert und nicht mit Schlaumeiersprüchen abgekanzelt werden.

 

[MiK]

Möglicherweise macht es keinen Sinn, so viele Caches zu aktualisieren. Aber ich kann es nicht beurteilen, ob Neo schlicht nicht über die Konsequenzen nachgedacht hat oder einen besonderen Grund dafür hat. Wenn er dafür künftig ein Login-Captcha kassiert, dann ist es sein Pech - nicht unseres.

Es wäre schön, wenn es so wäre. Aber solches Verhalten führt nicht nur zu Konsequenzen für ihn, sondern bestimmt auch zu generellen "Anpassungen" von GC. Darunter müssen dann alle leiden. Und als erstes die Entwickler, die versuchen damit zurecht zu kommen. Möglicherweise aber auch die User, weil einige Funktionen dann nicht mehr gehen oder wie zuletzt nur noch viel langsamer und umständlicher lösbar sind.

Deswegen kann man Leuten, die es übertreiben, nicht oft genug auf die Finger klopfen.

Zum Bug: Der ist nicht so leicht zu finden. Und es ist eben OpenSource. Das heißt, wenn ein Bug einen Entwickler nicht betrifft und er auch sonst nicht zu häufig auftritt, ist die Motivation eher gering dafür die Freizeit zu opfern. Auf der anderen Seite steht es dadurch jedem drei, einen Patch zu entwickeln, der den Bug fixt.

 

[schwaller]

sorry - aber wer so viele caches auf einen schlag spidern/aktualisieren will, dem gehört auf die finger geklopft und ich würde es sogar begrüssen, wenn das dann zum captcha etc bei demjenigen führen würde.

wie mik schon schrieb muessen derzeit leider alle unter diesem "fehlverhlten" einzelner leiden.

ich glaube kaum, das jemand manuell so viele caches irgendwie abrufen würde.

speicherprobleme bei der behandlung von solch grossen profilen sollte es jedoch nicht geben. die suche nach solchen lecks ist jedoch meist sehr aufwendig ;(

in diesem sinne eine bitte an alle: seit euch beim spidern/aktualisieren bitte immer bewusst, das grosse mengen schädlich für alle sind. eigentlich sind selbst kleine abfragemengen nicht erlaubt. (was ich jedoch auch für blödsinnig halte - erstrecht wo es offiziell nur ein megaumständliches verfahren gibt, welches die server recht stark belastet und ebenso für unnötigen traffic sorgt.) (technik hinweis: per mail lassen sich keine binärdateien übertargen - diese muessen zuvor immer in asciii gewandelt werden und somit vergrössern sie sich faktisch um den faktor ~1,5)

auch bin ich der meinung, das der automatisierte zugang für alle und nicht nur für meber zur verfügung stehen sollte.

aber nungut - an dieser stelle wirds dann eh schnell "politisch"

 

[arbor95]

...

Gibt es eines bekannte Obergrenze für die Java Applikation?
...

Siehe Startscript

...
Oder weiß jemand eine Lösung für diese Problem?
...

1. Möglicherweise siehe Startscript
2. kleinere Profile, gefundene in einem extra Profil verwalten
3. für ein vorhandenes Profil den Import erneut anwerfen, statt zu aktualisieren. Dabei werden dann nur die Cache aktualisiert, bei denen es eine Änderung gegeben hat.
4. nur die zu suchenden/zu lösenden Cache bearbeiten durch Zentrum + Entfernung für den Import setzen.

 

[skalar]

n Abend,

also nur um die Sache mal etwas klarer zu stellen, ich hab von updaten geschrieben, damit meinte ich aber via GPX (Pocket Queries) und nicht online über GC.... Hab nie von online updates geschrieben und werde ich mich auch nicht dazu bekennen dies zu machen, weil es schätzungsweise Tage dauern würde, bis so n Update unten ist, zudem benötige ich nicht wöchentlich einen 30 km Radius, der topaktuell ist...

Und blöd bin ich nämlich auch nicht und lesen kann ich die Statuten von GC selbst :zensur:

Deshalb sollte man lieber erst mal nachfragen was Sache ist, statt hier nur jemanden an den Pranger zu stellen.... Aber Flamer sterben halt in keinem Forum aus und das Moderatoren ohne Hintergrundinfo in die gleiche Bresche schlagen ist nur erbärmlich. Schade eigentlich!

Übrigens hab ich den BUG (wenn's einer ist) selbst gefunden, jedenfalls funktioniert der auf meinem Recher:

start javaw -Xms64M -Xmx1024M -cp CacheWolf.jar ewe.applet.Applet CacheWolf.CacheWolf

wird zu:

start javaw -Xms64M -Xmx2048M -cp CacheWolf.jar ewe.applet.Applet CacheWolf.CacheWolf

geändert, d.h. Die maximum Java heap size vergrößert und wow es lassen sich ca. 12000 Caches locker laden und verarbeiten... Mehr wollte ich gar nicht.

Noch n schönen Abend

 

[Inder]

Die 2048 nimmt er bei mir nicht. Hängt wohl vom physikalisch vorhandenen Speicher ab? Ich habe nur 2GB. Aber 1536 hat schon mal geklappt.

 

[arbor95]

da hat mein Tipp 1. ja was gebracht?
Ich dachte immer PQs sind auf 500 / 1000 begrenzt?

 

[arbor95]

Die 2048 nimmt er bei mir nicht. Hängt wohl vom physikalisch vorhandenen Speicher ab? Ich habe nur 2GB. Aber 1536 hat schon mal geklappt.

Daher ist der Ausdruck "bug" auch falsch. Natürlich hängt das vom vorhandenen Speicher ab. Deshalb wird die Datei auch mit einem kleinen Wert ausgeliefert.
Unabhängig davon könnte aber mal jemand schauen wo beim gpx-Import der Speicherfresser ist. Könnte auch an den benutzten Bibliotheken liegen....

 

[arbor95]

...

Und blöd bin ich nämlich auch nicht und lesen kann ich die Statuten von GC selbst :zensur:

...

Wer weiss (siehe dein geposteten Code)
....
at CacheWolf.imp.SpiderGC.getCacheByWaypointName(Unknown Source)
....

ist so wie ich das sehe kein gpx-Import.

 

[langlurch]

Könnt ihr vielleicht mal eine Grenze nennen (so als grobe Richtlinie), die man nicht überschreiten sollte?
"Ein paar Hundert" scheint ja unschädlich zu sein. Geht es aber vielleicht ein wenig konkreter?

 

[arbor95]

Könnt ihr vielleicht mal eine Grenze nennen (so als grobe Richtlinie)....

Grenze für was?

 

[Wutschkow]

Könnt ihr vielleicht mal eine Grenze nennen (so als grobe Richtlinie), die man nicht überschreiten sollte?
"Ein paar Hundert" scheint ja unschädlich zu sein. Geht es aber vielleicht ein wenig konkreter?

Da fragst Du am besten mal direkt bei Groundspeak an.
Aber im Ernst: Das kann hier niemand genauer sagen. Wirkliche Erfahrungswerte gibt es dazu auch nicht, oder? Ist halt auch eher selten, dass hier jemand postet "Ich habe gestern 3783 Caches gespidert und nun wurde ich gesperrt."

 

[Inder]

Die 2048 nimmt er bei mir nicht. Hängt wohl vom physikalisch vorhandenen Speicher ab? Ich habe nur 2GB. Aber 1536 hat schon mal geklappt.

Kurze Info für Betroffene.
Es liegt nicht am physikalischen Speicher, sondern an Microsoft. Habe jetzt 4GB (3 werden von XP erkannt) und nichts ändert sich.

Bei 32-Bit-Windows ist bei 1610M Schluss. Egal wie viel der PC hat.