Member Avatar for chuckc

I have an odd problem with a Java-based Internet program that I would like to use on a regular basis on my Windows XP computer. I have not done Java programming, so I would be interested to know if anyone has ideas about what might be happening.

The program runs perfectly when I first start it. At that point, Java uses between 10 and 20 percent of the CPU time. Running in the same manner, as far as what the program is doing, Java gradually uses more and more CPU time until after about an hour, javaw.exe is using about 100% or 99% of the CPU time on my computer, and while the program continues to work, it works extremely slowly at that point. There is no indication that the computer is running out of memory.

I have run the application on two different computers. One is a Dell computer with a 2.54 GHz CPU, 2 GB RAM, and plenty of hard drive space. To the best of my knowledge, Windows XP has all the latest updates, and I have completely removed and re-installed Java with different Java-versions several times. I have cleared out the Java cache, cleared out temporary Internet files, and the problem remains the same. Our Internet service is Verizon, very high speed fiber-optic, and although we occasionally get a packet failure, the error rate is very small. I use Avast anti-virus software and I believe that both computers are clean. We have no history of problems with any other Internet programs. I have not yet tried this with Windows 7, but while I suspect it would work OK, I would rather not upgrade for unrelated reasons. Nothing that I have done thus far makes any difference; the same thing happens every time I run the application for over an hour, give or take maybe 20 minutes.

The tech-support people insist that there is nothing wrong with their software, and that it runs fine on Windows XP, although having worked with software for a long time I am a little suspicious about this. Currently they think the problem is with my Internet service, and they want me to try using a different ISP. That is easier said than done.

Any ideas?
Thanks, Chuckc

  • 2 Contributors
  • 3 Replies
  • 259 Views
  • 3 Weeks Discussion Span
  • Latest Post Latest Post by chuckc

Dani AI

Generated

As later observed, switching from wireless to a hardwired link eliminated the progressive CPU climb; 's suggestion to look at paging was a sensible diagnostic step and enlarging the pagefile sometimes reduces symptoms. Those facts together point away from a simple Java memory leak and toward network-error driven work during the heavy market-data window.

How that commonly happens: intermittent packet loss under heavy throughput forces TCP retransmits and extra kernel/user-space work. A real-time client that aggressively retries, reconnects, or processes every incoming message without backoff can amplify the work-per-second as the network struggles. That produces lots of short-lived objects and/or busy threads, which raises CPU (and GC activity) without showing a huge steady memory increase.

A concise diagnostic sequence that matches what was seen:

  1. Measure packet loss and latency during market hours with continuous tests:
    ping -t broker.example.com
pathping broker.example.com
  2. Capture a short network trace (Wireshark) and look for retransmits/duplicate ACKs:
    Wireshark display filter: tcp.analysis.retransmission || tcp.analysis.duplicate_ack
  3. Correlate Java threads to CPU hotspots: collect repeated thread dumps and check native ids (jstack prints nid=0x...), then correlate with per-thread CPU in Process Explorer (convert IDs as needed).
    jstack -l <pid> > threaddump.txt
  4. Enable GC logging to see whether GC frequency climbs:
    -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

Mitigations beyond a wired connection: update NIC drivers and AP firmware, move the client/AP to a less congested band (5 GHz if possible), disable adapter power-saving, reduce interference or client count, and ask the vendor about exponential backoff or queue limits in the client. For long-term reliability and better tooling, consider running the client on a modern, supported OS and JVM.

Recommended Answers

All 3 Replies

Member Avatar for Taywin

If the only resource that are using to run the app is CPU %, not mem %, you may need to check "paging" activity as well. See if the paging occurs and how high it is. Because you said there seems to be no memory leak but the app increasingly consumes CPU as time goes by, it could be from the app/program itself that requires a certain source that cannot be kept permanently in the computer RAM. As a result, it needs to be swapped in and out (paging) and that could increase CPU usage. Just my two cents...

Member Avatar for chuckc

you may need to check "paging" activity

Seems like a good idea. I have increased the virtual memory paging file size, and that helps, but I don't think it completely fixes the problem. There may be other Windows settings that could be tweeked. It is difficult to know if a change helps because the increase in CPU % occurs very slowly.

The app is a stock market trading platform for a discount brokerage company. The increasing CPU % only seems to occur during normal trading hours, 9:30 to 4:00, when there is a lot of data coming in over the network. That limits the amount of time that I have to experiment.

Thanks for your "two cents"!

Member Avatar for chuckc

There were errors between our wireless server and the computer. Not bad enough to bother other applications, but apparently this one. Using a hardwired connection to the server instead of the wireless modem fixed the problem. I don't understand why occasional network problems would cause the cpu usage to increase cumulatively, so I think this is a workaround rather than a solution. But we will call it solved for now.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.