Inconsistent CPU usage

[Elliot]

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

 

[Patricia Shanahan]

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%. ....
while(!pW.isFinished){;}; // programmatic block to put up screen

From the point of view of a CPU dispatcher, a dual threaded CPU chip,
with dual threading enabled, is two logical processors, as is a dual
core chip with both cores enabled. A single thread can be reported
as taking up to 1/P of the compute power, where P is the number of
logical processors in the system.

I think you should look very closely at the numbers of logical
processors enabled on each system. Probably, each of the systems
reporting 50% utilization has two logical processors, and each of the
systems reporting 100% has a single logical processor.

Patricia

 

[Knute Johnson]

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.

 

[Christian]

while(!pW.isFinished){;}; // programmatic block to put up screen

Its no longer DOS you have Threads .. and you have several of them also
your OS might want some CPU power so its allways good to not use all at
least not for waiting.

If you want execution to just yield and wait for something best approach
would be to use wait()
use synchronize to get the monitor of an object then you can wait on it.
I would recommend you to exchange
while(!pW.isFinished){;};

with somthing like a call to a wait for finish method that could block
until finished (though call back might most times be better.. depends..)


the lazy method to fix your code would be sth like:
while(!pW.isFinished()) {
Thread.sleep(100);
};

if the finished variable is volatile or synchronized by some other means
this will work.

sun might have a learning trail for this.. GIYF

 

[Elliot]

From the point of view of a CPU dispatcher, a dual threaded CPU chip,
with dual threading enabled, is two logical processors, as is a dual
core chip with both cores enabled. A single thread can be reported
as taking up to 1/P of the compute power, where P is the number of
logical processors in the system.

I think you should look very closely at the numbers of logical
processors enabled on each system. Probably, each of the systems
reporting 50% utilization has two logical processors, and each of the
systems reporting 100% has a single logical processor.

Patricia

Thanks Patricia - it sure seems like a reasonable interpretation of
the usage percentages. We're checking it out

 

[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 - not really a helpful comment. How about pointing people in the
right direction?

 

[Elliot]

Hi Christian

Thanks for the friendly help and the ideas which I will research.

I wonder if anyone has example code to display a splash screen with
input fields and which then goes on to display the main application. .

Cheers

Elliot

 

[RedGrittyBrick]

Knute - not really a helpful comment. How about pointing people in the
right direction?

Without seeing the rest of the code it is hard to be more specifically
helpful. Not since the days of single tasking DOS has it been sensible
to burn CPU cycles in a tight loop as a method of waiting.

With a Swing application you should never need to do this, the whole
thing should by default be event driven.

e.g.
String pw = JOptionPane.showInputDialog(frame, "Enter Password");
new SocketyThing().start(pw);

The second statement won't be run until the first statement has been
completed (by user pressing "OK").

A more realistic example would put SocketyThing().start(pw) into a
SwingWorker - still no need for explicit waiting or signalling.

HTH.

 

[RedGrittyBrick]

Hi Christian

Thanks for the friendly help and the ideas which I will research.

I wonder if anyone has example code to display a splash screen with
input fields and which then goes on to display the main application. .

Here's some rubbish I dashed off in a couple of mins. It compiles, runs
and does what I expected it to do.

---------------------------- 8< ----------------------------
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;
import javax.swing.SwingWorker;


public class PwSocket {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new PwSocket();
}
});
}

PwSocket() {
final String pw = JOptionPane.showInputDialog("Password");

new SwingWorker<Void,Void>() {
@Override
protected Void doInBackground() throws Exception {
new SocketThing(pw).start();
return null;
}
}.execute();

JPanel p = new JPanel();
p.add(new JLabel("Your App goes here"));

JFrame f = new JFrame("Passworded Socket");
f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.add(p);
f.pack();
f.setLocationRelativeTo(null);
f.setVisible(true);
}

class SocketThing {
SocketThing(String pw) {
// Use pw to init stuff
}
public void start() {
// Network I/O here (off EDT)
}
}

}
---------------------------- 8< ----------------------------

HTH

 

[RedGrittyBrick]

Hi Christian

Thanks for the friendly help and the ideas which I will research.

I wonder if anyone has example code to display a splash screen with
input fields and which then goes on to display the main application. .

Here's some rubbish I dashed off in a couple of mins. It compiles, runs
and does what I expected it to do.
[snip]

I decided to use this as an opportunity to learn about java.net.Socket.

---------------------------- 8< ----------------------------
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;
import java.net.UnknownHostException;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;
import javax.swing.SwingWorker;

public class PwSocket {
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new PwSocket();
}
});
}

private JLabel label = new JLabel("Busy...");

PwSocket() {
final String pw = JOptionPane.showInputDialog("Password");

final SocketThing socketThing = new SocketThing(pw);

final JFrame f = new JFrame("Passworded Socket");

new SwingWorker<Void, Void>() {
@Override
protected Void doInBackground() throws Exception {
socketThing.start();
return null;
}
@Override
protected void done() {
if (socketThing.hasError()) {
JOptionPane.showMessageDialog(f,
socketThing.getErrorMessage());
System.exit(1);
} else {
label.setText("["+socketThing.getData()+"]");
}
}
}.execute();

JPanel p = new JPanel();
p.add(label);

f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
f.add(p);
f.pack();
f.setLocationRelativeTo(null);
f.setVisible(true);
}

class SocketThing {
private Socket sock;
private PrintWriter out = null;
private BufferedReader in = null;

private String errorMessage;
private String data;

SocketThing(String pw) {
System.out.println("Creating SocketThing...");
if (!pw.equals("Foo")) {
errorMessage = "Bad password!";
} else {
try {
sock = new Socket("www.google.com", 80);
out = new PrintWriter(sock.getOutputStream(), true);
InputStream is = sock.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
in = new BufferedReader(isr);
} catch (UnknownHostException e) {
e.printStackTrace();
errorMessage = e.getMessage();
} catch (IOException e) {
e.printStackTrace();
errorMessage = e.getMessage();
}
}
System.out.println("SocketThing created.");
}

public void start() {
System.out.println("Starting SocketThing...");
if (out != null) {
out.println("GET / HTTP/1.1");
out.println("");
try {
data = in.readLine();
} catch (IOException e) {
e.printStackTrace();
errorMessage = e.getMessage();
return;
}
}
System.out.println("SocketThing finished");
}

public boolean hasError() {
return errorMessage != null;
}

public String getErrorMessage() {
return errorMessage;
}

public String getData() {
return data;
}
}

}
---------------------------- 8< ----------------------------

 

[Roedy Green]

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

 

[Knute Johnson]

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."

 

[Elliot]

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

 

[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

 

[RedGrittyBrick]

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.

 

[Roedy Green]

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.

 

[Elliot]

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.

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