Good day support,

This security warning appears several times during this and last week.
I do not know if it is issue on my side, or not.
Please check.

You must specify your level of Java runtime, OS, etc. There can be bugs in
certain versions of Java as concerns mixed code or other "security"
concerns. There may be workarounds.

Also, what security scanning software (if any) is on your system?

This next question may not appear important to you, BUT it is important...

How long had the system been running continuously when the error
occured? There are bugs in the Java Web Start classloader which
cause certain classes to erroneously "unload" (be GC'd) after a period of time.

These are known bugs and there are workarounds for them. When
this BUG shows up, then you start getting just these exception types.

I'm pretty sure Dukascopy API engineers are aware of this type of
thing, since they (and I also) use Java Web Start extensively.

HyperScalper

Hi hyperscalper,

thanks for info.

This are some specifications about system:
Java Web Start 10.3.1.255
Using JRE version 1.7.0-b147 Java HotSpot(TM) 64-Bit Server VM
OS- Windows 7 Ultimate
Security program- Eset smart security 4.2.76.1
This configuration goes without problems until now.



This occures irregularly. Sometimes all is OK for hours, and sometimes it occures about few minutes after platform launch.
As you can see from java console log, there is uncaught exception in "com.dukascopy.dds2.greed.gui.component.chart.toolbar.f" class.
After this exception was unavailable f(x) button for adding indicator.
There was many exceptions with different classes.

For example see below another java console log. It happened when I wanted to run strategy. I could not start strategy ,strategy tab was unavailable and platform frozen.
I'm not saying it's platform issue, but it is annoying and I have to put right.

Hi.

SEE THE NEXT POST TO SEE THE REAL NATURE OF THE PROBLEM.

Thanks for the info. Here's my take on this problem, and what you should do about it.

It's YOUR system, so ultimately I can't tell you what to do !!

Strip off 64 bit Java, and install 32-bit Java. See if the problem comes back.

I am delighted to see you are using the Server VM. Do the same thing with the 32-bit Java.

I know we all think that 64-bit should be faster on a 64-bit chip, but actually I am told that 32-bit Java is FASTER.

All of my experience is with 32-bit Java, mostly because I have had to use 32-bit native DLL's from time to time....

Again, it's your system, and I have little experience with Java 7. I have frozen my versions at the end of the Java 6 series for a while.

I can almost guarantee you that the problem is with Java Web Start, and that the normal Java runtime does NOT have this problem.

The nature of the problem is that the Java Web Start ClassLoader permits key classes to be Garbage Collected.

This has the knock-on effect of security classes, and other such things being unavailable and/or Bogus security exceptions preventing the loading of certain classes....

HENCE the barrage of error messages relating to missing classes, etc....... SECURITY problems and "Trust Level" issues. These issues did not exist when you first started but while it was running, key security related / authentication classes are lost, and so then the authentication / "trust" security stuff fails forever, and there is no recovery.

For LONG RUNNING processes running under Java Web Start, in VM's which have this bug in Java Web Start, the only workaround I know of is to "lock down" classes so that they are NOT GC'd. These are Java Web Start entities which get "kicked out" of memory and thus cause this pathological situation. It's a Java Web Start BUG.

An example of this I have posted, which applies only to code where you are able to include the "fix" in your own startup.

If I were you, I'd nuke Java 7 and install the latest 32-bit Java 6 series update. But that's just me

So that you know this is a real problem, and that there is a workaround, I posted this workaround here:

viewtopic.php?f=65&t=48731

Problem is, it may be version specific, and so I don't know how generic it is. You could only use such an approach in your own code most likely, so it might not apply to you. Really pissed me off to know that Java had problems like this internally in the Java Web Start classloader. Maybe Oracle has made things better...

HyperScalper

There may be something you can set in the Java console related to trust
or mixed mode or security of some sort which could mitigate the
security problem which is a side effect of the classloader problem.

Let me see..... You might try disabling verification in the Java Console.

Not sure that will fix the issue but you could investigate.

Another thing you could do is to make sure you have a Huge heap so that
the GC problem is less likely to occur. If you filter the startup jnlp for
JForex you can provide a larger heap. Various approaches to doing this
elsewhere in this forum.

Even more relevantly, look at this !!! Shocking, ain't it ??
https://stackoverflow.com/questions/1090 ... rust-level

Here is some of the history of workarounds for this problem back with Java 6:
https://forums.oracle.com/forums/thread ... ID=1303543

See the post by user 855200 at the above link. Here's a quote from his post:


DUKASCOPY DEVELOPERS SHOULD CONSIDER INCLUDING THIS "FIX" IN THE
STARTUP TO JFOREX, OR AT LEAST SEE WHETHER IT IS RELEVANT. IT COULD
AVOID SOME ISSUES LIKE YOURS.

HyperScalper