Stuck on spinning "O" and ready message

[amisle]

We are running Servoy 3.1.8 on OS X Server 10.4 (Java 1.5.0_06-64). Clients are also running Java 1.5 - mix of Mac and PC.

The solution works fine in Servoy Developer. In Servoy Client, the solution sticks after login at the rotating "O" with a message of "Ready" at the bottom of the screen. Forms can be selected from the Window menu, and will then be displayed, but the global on open method I have set is not being executed.

Previous releases of this solution did not exhibit this problem. The release before this one, I believe I encountered the exact same problem, but we were still on 3.0.x. I upgraded to 3.1.8 and it went away. We are not ready to go to 3.5 yet, so I am not sure what else can be done. Plus, it seems like it will be a recurring problem so I would like to take care of it now.

I played with the solution settings and couldn't make any progress. I set the initial form to something else and turned off the on open method. The best I could get was a blank screen after loading (hiding the spinning "O" but never actually showing a form's contents without having to use the Window menu).

I have reverted to the previous version in the repository and all is well again, but I would like to deploy this newest version ASAP!

[rgansevles]

amisle

Try setting the webstart option 'Show console' in the Java Control Panel on the client machine before starting the smart client.

When you start the smart client now, a separate window will show up.
The logging may give a clue to the problem.

Rob

[amisle]

Good idea, Rob. Here's what I get:

Code: Select all

Exception in thread "AWT-EventQueue-0" java.lang.VerifyError: (class: org/mozilla/javascript/gen/c34, method: call signature: (Lorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;Lorg/mozilla/javascript/Scriptable;[Ljava/lang/Object;)Ljava/lang/Object;) Illegal target of jump or branch
   at java.lang.Class.getDeclaredConstructors0(Native Method)
   at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
   at java.lang.Class.getConstructors(Class.java:1446)
   at org.mozilla.javascript.ScriptRuntime.createFunctionObject(ScriptRuntime.java:2083)
   at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java:163)
   at org.mozilla.javascript.Context.compile(Context.java:1920)
   at org.mozilla.javascript.Context.compile(Context.java:1845)
   at org.mozilla.javascript.Context.compileFunction(Context.java:895)
   at com.servoy.j2db.scripting.f.compileFunction(Unknown Source)
   at com.servoy.j2db.scripting.f.getSolutionScope(Unknown Source)
   at com.servoy.j2db.FormManager.do(Unknown Source)
   at com.servoy.j2db.FormManager$1.run(Unknown Source)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
   at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)


Is this a Servoy error or something I caused? It would appear to be the former. Please let me know how I can resolve it!

[rgansevles]

amisle,

Try cleaning up all servoy webstart apps on your client.

If this does not help, is there a method that is very long?
I have seen some similar problems before with a very large javascript function. Splitting it in 2 separate solved the problem.

Rob

[amisle]

Could you provide some basic instructions for cleaning up the webstart apps on the client? Is that the same as clearing the cache?

I am not convinced it is the method causing the problem. I get the exact same behavior / stack trace no matter which startup method I select - even if I select none.

[ellenmeserow]

We call this the "4 minute donut call". A few times a year we get a phone call from a user who says "the donut has been spinning for four minutes and nothing is happening." Don't know why they OFTEN say 4 minutes, but they do. When this happens, we just throw away their .servoy folder on the client machine (found in the user directory) and then relaunch from the web http://yourserver:8080 and everything works again. Really annoying, but manageable.

[amisle]

I deleted ~/.servoy as Ellen suggested (funny!) and also the contents of ~/Library/Caches/Java/cache/javaws/http

I have seen the "4-minute donut" on many occasions, but it usually resolves itself if you wait long enough. I didn't know about the .servoy folder, actually.

After re-downloading all of the client files, I did find that appearance issues with the login dialog under Leopard were resolved... but, unfortunately, the critical issue still remained with an identical stack trace.

I am trying to bring this issue to the attention of Servoy Support. I filed a support request, but in the meantime, I would definitely appreciate any additional insight anyone has to offer. Thanks.

[sbutler]

For clearing your java cache, there is actually another way then manually deleting the files. You can see http://www.servoyguy.com/knowledge_base/deployment/how_do_i_clear_my_java_cache for instructions

A few questions...

1. What database are you using. If MySQL, what storage engine are you using (MyISAM, or InnoDB) on the repository server tables?

2. Not to be Mr. Obvious, but have you restarted the server?

3. Have you tried to export the solution, and then import into your local machine (running a local repository different than the server) to see if it works?

[amisle]

Scott, thanks for the quick reply!

I followed the procedure for clearing the cache on your website on another machine. Loaded the solution using Servoy Client and still witnessed the same behavior.


Replies to your questions:

1) MySQL with InnoDB tables.
2) Yes, about five times.
3) I exported the solution from my development machine (Mac Pro), where it worked fine, and then imported it using the web interface of Servoy Server (/servoy-admin) on our Xserve. I verified that it did not work in Servoy Client on any of the machines I tried, including my development machine. Subsequently, I verified that it DID work fine in Developer on the server. Next, I started up web services on my Developer machine and then connected to it using Servoy Client from various machines running both Mac and Windows. Again, the exact same behavior as on our server.

I should note that my development machine uses the default Sybase repository, while accessing the same MySQL data source. The server repository is in MySQL, again with InnoDB tables.

[sbutler]

Can you do a fresh install on your Mac Pro? Just install in another directory like /Applications/Servoy_temp. When you install, make sure you install the Database and Sample solutions. Then add the db connections to your MySQL data tables, but keep the repository in the same local sybase from your fresh install.

Next, test one of the sample solutions from Developer, and from a client connected to your developer. Is there the same problem?

Next, import your solution into this new Servoy_temp installation. Test again from developer and client. Is there the same problem?

[amisle]

Can you do a fresh install on your Mac Pro? Just install in another directory like /Applications/Servoy_temp. When you install, make sure you install the Database and Sample solutions. Then add the db connections to your MySQL data tables, but keep the repository in the same local sybase from your fresh install.

I did this, again using 3.1. First, I quit dbsrv9 from my existing Servoy installation. After I reinstalled, I opened Servoy and entered my Developer key and restarted. I verified that the _START_HERE solution worked in developer. I entered connections to the two MySQL tables and restarted again for good measure. Since my solution requires a login, I also created one administrator user.

Next, test one of the sample solutions from Developer, and from a client connected to your developer. Is there the same problem?

The sample solutions worked fine in client and developer, both before and after the import of my solution to the repository. This was also the case on my existing installation - only my solution exhibits the problem.

Next, import your solution into this new Servoy_temp installation. Test again from developer and client. Is there the same problem?

Works great in developer, just as on my existing installation.
But in client... foiled again! Same exact symptoms, same stack trace.

I verified this with three separate clean installations, properly unstalling between each one. I imported a particular solution into each:
- One from last week and my existing installation, when I originally noticed this problem
- One from tonight and my existing installation, believing the "last week" version could possibly be corrupted
- One exported from the second clean installation, after it was verified working in Developer

I'm stumped. Like I said, I have only seen this once before and it resolved itself somehow between 3.1 point updates.

[rgansevles]

amisle,

Please check all methods in your solution for size.
Is there a very large one?
Even if it is not called yet, it may be compiled on the client and fail on that.

If you find a large one, try splitting it in half and see if the solution works.

Rob

[sbutler]

In our support system, it shows that engineering has released updated jars to fix this problem. Can you verify that it is fixed?

[amisle]

Nope, the new jars did not fix the problem. I even tried with the same clean installation procedure, and the error was still present in Client (same stack trace, symptoms, and all). The jars updated my version number to 3.1.8_01.

I was impressed with the quick response!

[Andrei Costescu]

Did you check the length of your methods as Rob asked in an earlier post?
The exception you are getting usually happens because of a very large javascript method in your solution.

As while running in developer JS is interpreted - it does not appear in developer. In client however, the JS is compiled into Java for better performance and there is a limitation for the method size in Java (because of the no of bits used to perform jumps inside the method). So a large method (must be pretty large...) can cause this - in client.

If you find this kind of methods, please try to divide them into 2 or more smaller ones.