Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Community Reputation

0 Neutral

About kyt

  • Rank
  • Birthday 01/01/1
  1. kyt

    App server

    That is good news about Tomcat. Are there plans for Glassfish? Thanks
  2. kyt

    App rarely hangs on startup

    However, most of the objects in my application that are created on startup are global objects, so they are allocated on the heap. Still, I think there is a possibility that memory allocation may have issues in some conditions. Maybe the heap is not growing fast enough sometimes? I noticed, though, that when the "hangs" happened the process was taking 0% CPU and the allocated memory was about 36 Mb. I'm not sure how much of that allocated memory was for the heap. This heap suspicion is just speculation at this point.
  3. kyt

    App rarely hangs on startup

    No news so far .. just a question: I think this problem may have also be caused by memory allocation issues. If you noticed in settings I allocate objects on Stack. I had the stack size of about 900 K. This seems kind of low for the number of GUI and other objects I have to create on startup. What do you (Jet run time) do when the size of allocated objects reaches the maximum allowed? Thanks
  4. kyt

    App rarely hangs on startup

    I can't reproduce the problem with my old code. I'm not sure why. It is possible that some bad code was taken out or there were some other code changes that modified the behavior. I will be visiting this issue from time to time. I have set up a test and logging environment specifically to monitor this issue, so may be I will have news someday.
  5. kyt

    App rarely hangs on startup

    I will also try to reproduce the problem with trial version Desktop Runtime.
  6. kyt

    App rarely hangs on startup

    Yes, absolutely. The whole application has been checked and rechecked many times to make sure the Swing single thread (EDT) policy is always followed. It looks like the execution is not getting to mf.setVisible(true); This may be caused by some kind of exception in the previous method (the main form constructor). I will try to catch that exception, if it does indeed exist. OK, I will call it a hangcident.
  7. kyt

    App rarely hangs on startup

    ...under normal (single start) conditions.
  8. kyt

    App rarely hangs on startup

    Yes. I have to say that the application performs well once it's started. It's a complex system that talks to some devices and updates many Swing components -- it's a multi-threaded thing that can and does get very intense, but it never hangs or crashes. I may some day provide a sample, but at this time I don't see that I can do it -- I can't provide the original (I assume you want the source code) and making a working prototype takes time. To elaborate on the old code description: The main form constructor is very simple but long. It reads a settings file, builds the GUI and starts a simple thread that loads some DLLs and instantiates a file chooser. The DLLs are not used until after the constructor and the "loading" thread are long finished. Do you think there is a chance that the problem can be caused by the amount of code that has to be executed in one take without any sleeps? Also, I noticed that the problem surfaced more often when many application instances were started quickly one after another. No one saw this problem -- not the QA, not the customers -- just me. So I assume it's very rare. I run Ubuntu Linux and XP on the same machine -- Dell Precision with 2G memory and a dual 2.4 GHz Intel CPU. I have never seen this problem one my single core machines. Some Jet settings: -compilewithfixedheap- -gendll- -genstackalloc+ -genstacktrace- -global- -gui- -ignoreclassduplication+ -ignorememberabsence+ -inline+ -jetcpenablemanualsettings+ -splashcloseonawtwindow- -splashcloseonclick- -splashgetfrommanifest- -classabsence=HANDLE -compilerheap=0 -heaplimit=245946856 -inlinelimit=50 -inlinetolimit=250 -jetcplastpage:=PageOptions -jetrt=Classic -jetvmprop=-Djava.library.path:lib -Djet.jit.fast -Djet.gc.heaplimit:245946856
  9. Since that has been brought up... I have run into crashes on startups often (1 crash in about 500-600 startups). But I have managed to reduce the problem to ...an infinitely small one -- I never have seen it since the fix. I never saw such crashes when the application was run as a "byte code". OLD CODE DESCRIPTION: The application's main class uses "invokeLater stuff" to construct and bring up the main form (JFrame) of the application. The constructor of the frame is quite large -- about 1600 lines of code, mainly dealing with Swing. Also, a slow (500 ms) utility "javax.swing.Timer" is started at the end of the constructor (This timer updates some portions of the main frame). So the run() in Runnable invoked in the main class goes something like this: mf = new MF(...); mf.setVisible(true); This is a legitimate way to deal with Swing. Crash: Sometimes, when the compiled application started with the old code, I would see the process start in the system monitor (Linux) or task manager (Windows), but the main form would not show up. If the application was built to show a splash-screen, the splash screen would show and hang forever (the splash-screen was set to close when a form is shown -- Jet feature), but the application process was there (showing in the system monitor). NEW CODE DESCRIPTION: I modified the code. Now there are sleep(20) calls inserted throughout the constructor -- in about 20 places. The utility timer "starting" call is moved out of constructor into run() of the Runnable. So NOW the run() in Runnable invoked in the main class goes something like this (notice sleeps there too): mf = new MF(...); sleep(150); mf.setVisible(true); sleep(150); mf.startTimer(); I use Jet 6.4 Standard on Linux and the other one. JRE 1.6.0_10. Crashes happened on both.
  10. kyt

    external libs

    Can you tell me how strict is this policy? I have been able to recompile the main project and use the old dependent DLL's without problems. Thank you.
  11. kyt


    I see that Sun fixed this bug in 1.6.0_11
  12. I see that Sun has fixed this bug in 1.6.0_10
  13. In this case, I can only make judgments about what I see, and what I see is that JOptionPane malfunctions. I will leave it to Sun to figure out what exactly causes the problem.
  14. vote for this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6734185