«

On Tue, 29 Apr 2008 13:44:53 -0700 (PDT), Elliot <>
wrote, quoted or indirectly quoted someone who said :

>while(!pW.isFinished){;}; // programmatic block to put up screen
>
>This waits (by looping) for the boolean to be set to true while the
>password is verified via the socket connection with Cobol.

That's a great way to chew up all the CPU time. Add a sleep in the
loop to avoid hammering the CPU.

See http://mindprod.com/jgloss/sleep.html
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Elliot wrote:
> On Apr 29, 5:46 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
> wrote:
>> Elliot wrote:
>>> Hi
>>> Our Java Swing application uses sockets to communicate with a backend
>>> Cobol database application. On 10% of the machines where the
>>> application is running CPU usage goes to 100% at startup. On the
>>> other 90% of the machines CPU usage is around 50%.
>>> I develop on a P4 3.06 Gh Dell with XP SP2 and 1 gig of ram and run
>>> at 50%. At one of our clients with the same P4 3.06 Gh and 2 gigs of
>>> ram the application loads much slower and runs at 100%.
>>> Perhaps the coding is part of the problem. A login screen is displayed
>>> at the start of the application. In order to get the application to
>>> stop and wait for user input the following line of code was used.
>>> while(!pW.isFinished){;}; // programmatic block to put up screen
>>> This waits (by looping) for the boolean to be set to true while the
>>> password is verified via the socket connection with Cobol.
>>> However, it takes many seconds to even get to this line. Java just
>>> seems really slow to load.
>>> I'm wondering how to understand the difference between the machines. I
>>> also wonder if there are any java startup options that might help.
>>> Both machines are using java "1.6.0_05" and we are loading a jar
>>> file. Any ideas are most welcome
>>> Thanks
>>> Elliot
>> while(!pW.isFinished){;}; // programmatic block to put up screen
>>
>> If the rest of your code looks at all like this, I'm surprised it runs
>> at all. You just cannot do this with Java and expect anything to work.
>>
>> --
>>
>> Knute Johnson
>> email s/nospam/linux/
>>
>> --
>> Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
>> ------->>>>>>http://www.NewsDemon.com<<<<<<------
>> Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
>
> Knute - not really a helpful comment. How about pointing people in the
> right direction?

Well what did you expect when you posted that code? It is obvious you
have no idea what you are doing. That code will eat up every bit of
processor time it can and that is probably why your program takes so
long to do anything else. You aren't clear whether this is a Swing GUI
program or not but if that code is running in your EDT, nothing else is
going to work right.

The fact that you don't know that makes it very difficult to answer your
question, which is probably a side effect rather than your problem.

You need to post enough of a description and/or your code, GUI (AWT or
Swing), command line, single or multi-threaded, and OS environment and
problem so that people really have an idea what you want to know.
Posting a SSCCE is also very helpful.

A guy goes into the doctor and says "doctor it hurts when I do that" and
the doctor says "well don't do that anymore."

--

Knute Johnson
email s/nospam/linux/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Hi Christian

I opted for the lazy method as least as an interim approach

> while(!pW.isFinished()) {
> Thread.sleep(100);
>
> };

AND Cpu usage is now back to zero most of the time.

I have done some homework since I started the thread and now have a
much better understanding of how threads work

Thanks for the help

Elliot

Hi Red...

I believe we may be having a misunderstanding about the role of the
sockets routines with Cobol.

This must be synchronous not asynchronous. We must get and validate
the user name and password before the application can continue. In
fact, the sockets routines are used most of the time to translate text
based Cobol screens into the Swing equivalents and to send user input
back to Cobol. So I don't understand why you want to start another
thread using SwingWorker to handle to handle this.

As I said to Christian, Thread.sleep(100)is working, but after doing
some reading I wonder if I could or should use "invokeAndWait" to
display the splash screen and validate the password. I know the normal
practice is to use "invokeLater", but I really do want to wait.

What do you think?

Elliot

Elliot wrote:
> Hi Red...
>
> I believe we may be having a misunderstanding about the role of the
> sockets routines with Cobol.

Posting an SSCCE is usually a good way of avoiding misunderstandings.
Not all of us have a backend COBOL database to hand so you should bear
that in mind when composing an SSCCE.

> This must be synchronous not asynchronous.

I understand those terms but I get the feeling you are using them in an
unusual way. Perhaps you mean consecutive rather than concurrent?

> We must get and validate the user name and password before the
> application can continue.

That is what my example does. I suppose I could make this clearer in the
code.

> In fact, the sockets routines are used most of the time to translate
> text based Cobol screens into the Swing equivalents and to send user
> input back to Cobol.

OK, that's often referred to as screen-scraping. If I was doing that I'd
look for higher level classes that implement telnet and emulate some
sort of ANSI (or other) terminal - sufficiently well to decode cursor
positioning sequences. Presumably you are doing something similar.

> So I don't understand why you want to start another thread using
> SwingWorker to handle to handle this.

Because you don't want your GUI frozen whilst your back-end COBOL
database spends 2s busy on a complex database query.

You may want the GUI to wait but you also want it to be able to re-draw
itself if some other app throws up a dialogue box that temporarily
obscures it. You may even want the user to be able to click a cancel
button to interrupt a long transaction. Hence SwingWorker.

>
> As I said to Christian, Thread.sleep(100)is working, but after doing
> some reading I wonder if I could or should use "invokeAndWait" to
> display the splash screen and validate the password. I know the
> normal practice is to use "invokeLater", but I really do want to
> wait.
>
> What do you think?

invokeAndWait seems more appropriate.

--
RGB

On Wed, 30 Apr 2008 01:52:55 +0200, Christian <> wrote,
quoted or indirectly quoted someone who said :

>Its no longer DOS you have Threads
There were various ways of adding threads to DOS. The OS of course
knew nothing about them. Recall DESQView and various ways of breaking
the 640K barrier.


--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Hi Red...

Using the following terms is fine.

> Perhaps you mean consecutive rather than concurrent?

In fact the contents of the GUI is dependent on the user login
information. Different menus for different users. So this information
must be validated before the GUI can be painted. We are connecting
with an rexec service which does the initial validation. This occurs
very rapidly and then the menu is determined, also quite rapidly ( a
few seconds). Maybe describing this process as being on a "critical
path" would make it clearer that starting another thread to do the
Cobol database operations would not work.

> You may want the GUI to wait but you also want it to be able to re-draw
> itself if some other app throws up a dialogue box that temporarily
> obscures it.

Our splash screen is modal and this hasn't been a problem so far.

I'm still thinking about the following.

>You may even want the user to be able to click a cancel

However, we do have a cancel button which is disabled until an error
message for an unsuccessful login is displayed. So it's true that the
gui would be more responsive by using another thread would could be
notified when the cancel button was pressed.


Concerning the "screen-scraping":

> OK, that's often referred to as screen-scraping. If I was doing that I'd
> look for higher level classes that implement telnet and emulate some
> sort of ANSI (or other) terminal - sufficiently well to decode cursor
> positioning sequences. Presumably you are doing something similar.

For various reasons we didn't choose the telnet approach. We do our
own translations for screen position and field attributes all of which
has worked out very successfully.


> > As I said to Christian, Thread.sleep(100)is working, but after doing
> > some reading I wonder if I could or should use "invokeAndWait" to
> > display the splash screen and validate the password. I know the
> > normal practice is to use "invokeLater", but I really do want to
> > wait.
>
> > What do you think?
>
> invokeAndWait seems more appropriate.

I'll give invokeAndWait a try.

I'd like to thank everyone who contributed to this "thread". It's been
a real education.

Elliot
> --
> RGB