Hibiscus Saldenabfrage bei einigen Sparkassen unglaublich langsam

1
2
3
4
5
…
11
12
13
Seite 4 von 13

sylvio2000

Benutzer

Geschlecht: keine Angabe
Beiträge: 10
Dabei seit: 08 / 2013

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 26.04.2016 - 18:47 Uhr · #61

Ich würd die ja gerne helfen, aber woran erkenne ich denn die PID?

Wenn ich "ps axu | grep jameica" ausführe (während Hibiscus gestartet ist) erhalte ich folgende Ausgabe:

sylvio@sylvio-Notebook:~$ ps axu | grep jameica
sylvio 6242 0.0 0.0 4508 712 ? S 18:43 0:00 sh /opt/jameica/jameica.sh
sylvio 6250 54.3 8.5 4172176 335648 ? Sl 18:43 1:00 javaruntime/bin/java -Djava.net.preferIPv4Stack=true -Xmx256m -jar jameica-linux64.jar
sylvio 6310 0.0 0.0 21316 1028 pts/1 S+ 18:45 0:00 grep jameica

Was genau ist jetzt hier die PID?

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10761
Dabei seit: 03 / 2005

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 26.04.2016 - 19:03 Uhr · #62

6250

sylvio2000

Benutzer

Geschlecht: keine Angabe
Beiträge: 10
Dabei seit: 08 / 2013

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 27.04.2016 - 22:13 Uhr · #63

Code

sylvio@sylvio-Notebook:~$ jstack -l 3416
2016-04-27 22:11:29
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.91-b14 mixed mode):

"Attach Listener" #31 daemon prio=9 os_prio=0 tid=0x00007f40b4001000 nid=0xe1e waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
  - None

"H2 Log Writer HIBISCUS" #29 daemon prio=5 os_prio=0 tid=0x00007f40e5dae800 nid=0xd89 in Object.wait() [0x00007f4078c5e000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  at org.h2.store.WriterThread.run(WriterThread.java:105)
  - locked <0x00000000f0e704a8> (a org.h2.store.WriterThread)
  at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
  - None

"H2 File Lock Watchdog /home/sylvio/.jameica/hibiscus/h2db/hibiscus.lock.db" #28 daemon prio=9 os_prio=0 tid=0x00007f40e5a11800 nid=0xd88 waiting on condition [0x00007f4078d5f000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
  at java.lang.Thread.sleep(Native Method)
  at org.h2.store.FileLock.run(FileLock.java:493)
  at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
  - None

"Timer-1" #25 daemon prio=5 os_prio=0 tid=0x00007f40e5d87000 nid=0xd85 in Object.wait() [0x00007f407abf8000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  at java.util.TimerThread.mainLoop(Timer.java:552)
  - locked <0x00000000f0e71280> (a java.util.TaskQueue)
  at java.util.TimerThread.run(Timer.java:505)

   Locked ownable synchronizers:
  - None

"pool-1-thread-1" #24 prio=5 os_prio=0 tid=0x00007f40e5538000 nid=0xd7b waiting on condition [0x00007f4079561000]
   java.lang.Thread.State: WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x00000000f06f8718> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
  at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
  - None

"date watcher for statusbar calendar" #23 prio=5 os_prio=0 tid=0x00007f40e5464000 nid=0xd7a waiting on condition [0x00007f407a425000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
  at java.lang.Thread.sleep(Native Method)
  at de.willuhn.jameica.gui.StatusBarCalendarItem$Worker.run(StatusBarCalendarItem.java:118)

   Locked ownable synchronizers:
  - None

"UpdateService" #21 daemon prio=5 os_prio=0 tid=0x00007f40e53a7800 nid=0xd79 in Object.wait() [0x00007f407a9f6000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  - waiting on <0x00000000f0e72940> (a java.util.TaskQueue)
  at java.util.TimerThread.mainLoop(Timer.java:552)
  - locked <0x00000000f0e72940> (a java.util.TaskQueue)
  at java.util.TimerThread.run(Timer.java:505)

   Locked ownable synchronizers:
  - None

"Timer-0" #20 daemon prio=5 os_prio=0 tid=0x00007f40e53a4800 nid=0xd78 in Object.wait() [0x00007f407aaf7000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  at java.util.TimerThread.mainLoop(Timer.java:552)
  - locked <0x00000000f0e72e40> (a java.util.TaskQueue)
  at java.util.TimerThread.run(Timer.java:505)

   Locked ownable synchronizers:
  - None

"Abandoned connection cleanup thread" #15 daemon prio=5 os_prio=0 tid=0x00007f40e5185000 nid=0xd74 in Object.wait() [0x00007f407acf9000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
  - locked <0x00000000f077f340> (a java.lang.ref.ReferenceQueue$Lock)
  at com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:43)

   Locked ownable synchronizers:
  - None

"GC Daemon" #14 daemon prio=2 os_prio=0 tid=0x00007f40e5123800 nid=0xd73 in Object.wait() [0x00007f407adfa000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  - waiting on <0x00000000f077f370> (a sun.misc.GC$LatencyLock)
  at sun.misc.GC$Daemon.run(GC.java:117)
  - locked <0x00000000f077f370> (a sun.misc.GC$LatencyLock)

   Locked ownable synchronizers:
  - None

"RMI Reaper" #13 prio=5 os_prio=0 tid=0x00007f40e5100800 nid=0xd72 in Object.wait() [0x00007f407b0fb000]
   java.lang.Thread.State: WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  - waiting on <0x00000000f077f4f8> (a java.lang.ref.ReferenceQueue$Lock)
  at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
  - locked <0x00000000f077f4f8> (a java.lang.ref.ReferenceQueue$Lock)
  at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
  at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351)
  at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
  - None

"RMI TCP Accept-0" #12 daemon prio=5 os_prio=0 tid=0x00007f40e50fe000 nid=0xd71 runnable [0x00007f407b1fc000]
   java.lang.Thread.State: RUNNABLE
  at java.net.PlainSocketImpl.socketAccept(Native Method)
  at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
  at java.net.ServerSocket.implAccept(ServerSocket.java:545)
  at java.net.ServerSocket.accept(ServerSocket.java:513)
  at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400)
  at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372)
  at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
  - None

"Session Worker Thread" #10 prio=5 os_prio=0 tid=0x00007f40e46d6000 nid=0xd6a waiting on condition [0x00007f408e946000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
  at java.lang.Thread.sleep(Native Method)
  at de.willuhn.util.Session$Worker.run(Session.java:313)

   Locked ownable synchronizers:
  - None

"Logger-Thread" #9 daemon prio=5 os_prio=0 tid=0x00007f40e4266800 nid=0xd67 waiting on condition [0x00007f40cf99d000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
  at java.lang.Thread.sleep(Native Method)
  at de.willuhn.logging.Logger$LoggerThread.run(Logger.java:418)

   Locked ownable synchronizers:
  - None

"Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00007f40e4199800 nid=0xd65 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
  - None

"C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f40e4184000 nid=0xd64 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
  - None

"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f40e4182800 nid=0xd63 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
  - None

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f40e417f800 nid=0xd62 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
  - None

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f40e417e000 nid=0xd61 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
  - None

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f40e414b000 nid=0xd60 in Object.wait() [0x00007f40d4af9000]
   java.lang.Thread.State: WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  - waiting on <0x00000000f0311688> (a java.lang.ref.ReferenceQueue$Lock)
  at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
  - locked <0x00000000f0311688> (a java.lang.ref.ReferenceQueue$Lock)
  at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
  at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

   Locked ownable synchronizers:
  - None

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f40e4146000 nid=0xd5f in Object.wait() [0x00007f40d4bfa000]
   java.lang.Thread.State: WAITING (on object monitor)
  at java.lang.Object.wait(Native Method)
  - waiting on <0x00000000f0311658> (a java.lang.ref.Reference$Lock)
  at java.lang.Object.wait(Object.java:502)
  at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
  - locked <0x00000000f0311658> (a java.lang.ref.Reference$Lock)
  at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

   Locked ownable synchronizers:
  - None

"main" #1 prio=5 os_prio=0 tid=0x00007f40e4009800 nid=0xd59 runnable [0x00007f40ed743000]
   java.lang.Thread.State: RUNNABLE
  at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
  at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(Unknown Source)
  at org.eclipse.swt.widgets.Display.eventProc(Unknown Source)
  at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
  at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(Unknown Source)
  at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
  at de.willuhn.jameica.gui.GUI.loop(GUI.java:913)
  at de.willuhn.jameica.gui.GUI.init(GUI.java:324)
  at de.willuhn.jameica.system.Application.init(Application.java:148)
  at de.willuhn.jameica.system.Application.newInstance(Application.java:90)
  at de.willuhn.jameica.Main.main(Main.java:78)

   Locked ownable synchronizers:
  - None

"VM Thread" os_prio=0 tid=0x00007f40e413e800 nid=0xd5e runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f40e401f000 nid=0xd5a runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f40e4020800 nid=0xd5b runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f40e4022800 nid=0xd5c runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f40e4024000 nid=0xd5d runnable

"VM Periodic Task Thread" os_prio=0 tid=0x00007f40e41a4000 nid=0xd66 waiting on condition

JNI global references: 2612

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10761
Dabei seit: 03 / 2005

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 27.04.2016 - 22:33 Uhr · #64

Danke fuer den Thread-Dump. Kannst du mal bitte mit SWT 4.5 testen, wie ich in http://www.onlinebanking-forum…real124414 geschrieben habe? Der einzige Thread, der fuer den Haenger in Frage kommt, ist naemlich der Event-Loop von SWT selbst.

Ich wuerde fast vermuten, dass das Problem auch nur bei manchen Distributions-Versionen - naemlich nur bei welchen mit einer bestimmten GTK-Version - auftritt.

Ausserdem koenntest du auch mal mit GTK3 testen -siehe http://onlinebanking-forum.de/forum/topic.php?t=19545

Hugo66

Benutzer

Geschlecht: keine Angabe
Beiträge: 9
Dabei seit: 04 / 2016

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 11:33 Uhr · #65

Hallo,

wie schon weiter oben erwähnt, funktioniert der Workaround bei mir leider nicht.

Ich habe nun auch mal GTK3 und SWT 4.5 getestet. Leider auch beides ohne Erfolg.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10761
Dabei seit: 03 / 2005

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 11:57 Uhr · #66

Zitat geschrieben von Hugo66

Hallo,

wie schon weiter oben erwähnt, funktioniert der Workaround bei mir leider nicht.

Ich habe nun auch mal GTK3 und SWT 4.5 getestet. Leider auch beides ohne Erfolg.

Und wie sieht bei dir der Thread-Dump aus? Vielleicht kann man an dem ja was erkennen.

Hugo66

Benutzer

Geschlecht: keine Angabe
Beiträge: 9
Dabei seit: 04 / 2016

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 13:25 Uhr · #67

Habe das mit dem Thread Dump jetzt gerade über eine Stunde lang probiert. Bekomme dieses jstack aber leider nicht zum laufen. Wahrscheinlich verbocke ich irgendetwas bei der Installation des JDK.

Gibt's noch eine andere Möglichkeit unter Opensuse mit Bordmitteln einen Dump zu erstellen? Ansonsten gebe ich hier jetzt auf. Habe da schon zu viel Zeit reingesteckt.

sylvio2000

Benutzer

Geschlecht: keine Angabe
Beiträge: 10
Dabei seit: 08 / 2013

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 17:40 Uhr · #68

Ich habe jetzt mal die swt.jar (4.5) ausgetauscht. Leider habe ich nun nur noch ein weßes Fenster nachdem ich das Passwort eingegeben habe.
Und in der jameica.sh steht nirgends was von swt.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10761
Dabei seit: 03 / 2005

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 17:45 Uhr · #69

Zitat geschrieben von sylvio2000

Und in der jameica.sh steht nirgends was von swt.

Ich weiss ja nicht, woher deine "jameica.sh" stammt. Aber in den originalen Downloads von www.willuhn.de sieht die letzte Zeile der jameica.sh so aus:

Code

LIBOVERLAY_SCROLLBAR=0 GDK_NATIVE_WINDOWS=1 SWT_GTK3=0 exec java -Djava.net.preferIPv4Stack=true -Xmx512m $_JCONSOLE -jar jameica-linux${archsuffix}.jar $@

Das "SWT_GTK3=0" muss gegen "SWT_GTK3=1" ersetzt werden, um mit GTK3 zu testen. Wie sieht denn deine "jameica.sh" aus? Und wenn anders - woher stammt deine Jameica-Installation dann?

sylvio2000

Benutzer

Geschlecht: keine Angabe
Beiträge: 10
Dabei seit: 08 / 2013

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 17:52 Uhr · #70

Ich hab den Installer benutzt. Meine jameica.sh sieht so aus:

Code

#!/bin/sh

# Linux Start-Script fuer regulaeren Standalone-Betrieb.
# Jameica wird hierbei mit GUI gestartet.

#_JCONSOLE="-Dcom.sun.management.jmxremote"

# https://www.willuhn.de/bugzilla/show_bug.cgi?id=774
# https://www.willuhn.de/bugzilla/show_bug.cgi?id=798

link=$(readlink -f "$0")
dir=$(dirname "$link")
cd "$dir"

bit=`uname -m |grep 64`
if [ $? = 0 ]
then LIBOVERLAY_SCROLLBAR=0 GDK_NATIVE_WINDOWS=1 javaruntime/bin/java -Djava.net.preferIPv4Stack=true -Xmx256m $_JCONSOLE -jar jameica-linux64.jar $@
else LIBOVERLAY_SCROLLBAR=0 GDK_NATIVE_WINDOWS=1 javaruntime/bin/java -Djava.net.preferIPv4Stack=true -Xmx256m $_JCONSOLE -jar jameica-linux.jar $@
fi

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10761
Dabei seit: 03 / 2005

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 17:57 Uhr · #71

Zitat geschrieben von sylvio2000

Ich hab den Installer benutzt. Meine jameica.sh sieht so aus:

Sorry. Da kann ich nicht helfen. Von mir stammen die Downloads direkt von www.willuhn.de. Ich bin der Autor des Programms. Das ist meine Webseite und ich selbst veroeffentliche die Releases nur dort. Wenn ihr Jameica/Hibiscus aus anderen Quellen installiert, habe ich keine Informationen, ob und was an diesen Downloads geaendert wurde.

Frage in den Raum: Kann es sein, dass alle User, die hier in diesem Thread von dem Problem berichten, Jameica/Hibiscus ebenfalls nicht direkt von www.willuhn.de bezogen haben sondern aus anderen Quellen? Wenn das der Fall ist, hätten wir uns hier eventuell 12 Seiten Diskussion und mühevolle Fehlersuche schenken können. Das würde auch erklären, warum ich den Fehler selbst nicht reproduzieren kann.

sylvio2000

Benutzer

Geschlecht: keine Angabe
Beiträge: 10
Dabei seit: 08 / 2013

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 19:00 Uhr · #72

Ich hab jameica komplett entfernt un die Version von die mit einem neuen Profil gestartet. Allerdings gibt es hier Probleme die scheinbar was mit Java zu tun haben.

Wenn ich nach dem ersten Start ""Plugins online suchen" oder "online Updates aktivieren" wähle bekomme ich folgenden Fehler:

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10761
Dabei seit: 03 / 2005

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 19:18 Uhr · #73

http://www.onlinebanking-forum.de/forum/topic.php?t=18489

Zweiter Treffer beim Googlen nach "jameica ec algorithmparameters not available"

sylvio2000

Benutzer

Geschlecht: keine Angabe
Beiträge: 10
Dabei seit: 08 / 2013

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 19:38 Uhr · #74

OK. Ich habe jetzt Oracle Java installiert. Die Fehlermeldung kommt nun nicht mehr

Jetzt gehts weiter

sylvio2000

Benutzer

Geschlecht: keine Angabe
Beiträge: 10
Dabei seit: 08 / 2013

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 21:46 Uhr · #75

Ich hab mein Backup eingespielt. Alles funktioniert wie gewohnt.

Hugo66

Benutzer

Geschlecht: keine Angabe
Beiträge: 9
Dabei seit: 04 / 2016

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 28.04.2016 - 22:33 Uhr · #76

Zitat geschrieben von hibiscus

Frage in den Raum: Kann es sein, dass alle User, die hier in diesem Thread von dem Problem berichten, Jameica/Hibiscus ebenfalls nicht direkt von www.willuhn.de bezogen haben sondern aus anderen Quellen?

Nein, meine Dateien stammen alle ausschließlich von willuhn.de. Und zwar die nightly-Versionen mit aktuellem Stand vom letzten Wochenende.

Roadster

Benutzer

Geschlecht: keine Angabe
Beiträge: 78
Dabei seit: 03 / 2016

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 29.04.2016 - 08:53 Uhr · #77

Meine stammen ausschließlich von Entwicklers Seite.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10761
Dabei seit: 03 / 2005

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 29.04.2016 - 08:58 Uhr · #78

Dann weiss ich es auch nicht mehr. Mit dem Wechsel von GTK2/GTK3, den verschiedenen SWT- und Java-Versionen sowie eventuellen Netzwerk-Problemen haben wir alle in Frage kommenden Moeglichkeiten ausgeschoepft. Ich weiss nicht, warum das da haengt. Ich kann auch an dem Thread-Dump nichts verdaechtiges sehen.

Roadster

Benutzer

Geschlecht: keine Angabe
Beiträge: 78
Dabei seit: 03 / 2016

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 29.04.2016 - 09:26 Uhr · #79

Ich habe einen bekannten, der bei einer anderen Sparkasse arbeitet gefragt, ob die Möglichkeit besteht, gezielt eine bestimmte Onlinebankingsoftware zu behindern oder zu verbieten. Er verneinte diese Möglichkeit.

Roadster

Benutzer

Geschlecht: keine Angabe
Beiträge: 78
Dabei seit: 03 / 2016

Betreff:

Re: Hibiscus Saldenabfrage bei Sparkasse Lüdenscheid unglaublich langsam

· Gepostet: 29.04.2016 - 09:32 Uhr · #80

Könnte ich eine funktionierende Version reproduzieren, wenn ich ein altes XP System oder eine ältere Linux Version mit einem älteren Java aufsetze und dann eine ältere Version von Jameica/Hibiscus installiere und keine Updates zulasse?

1
2
3
4
5
…
11
12
13
Seite 4 von 13