Still Freezing, 100% CPU usage

[j1900q]

I can't believe we are still having problems with this freezing. I would think this should be on the top of the repair list.
Keith

[eSignal_ToddI]

If you are experiencing freezing, or 100% CPU usage issues, it may be related to another program on your system. Perhaps try testing this by turning off different programs running in your system tray, to see if it changes your performance.

We recently found out that Computer Associates Personal Firewall can cause connection problems with LiveCharts 2.0.

Engineering is looking into possible causes of freezing, but as yet we haven't reproduced these types of problems in house.

[dannol48]

The only times I've experienced the 100% CPU were in conjunction with an error in the log, like the array error I've previously posted. I "pushed" that error in testing to cause the failure, so there is a possible tie from array error....to leak....to 100% CPU.

I believe I may now have a linkage to that error. I noted that one of the portfolios I built was not alphabetically sorted (is that normal or abnormal?). In attempting to remove a Row (symbol), it would only temporarily remove the symbol and would reappear the next time the portfolio was loaded. I was also seeing a string of Java errors in the log associated with that load. That portfolio was created during the time I didn't have stability, i.e. I have the Computer Assoicates firewall product and discovered that linkage to failure, so errors in handling the disconnect problem that technically shouldn't be possible may also spawn other corruption (no direct proof). By deleting the problem portfolio and rebuilding it using the comma delimiter (bulk) method, that portfolio is now working OK. I haven't tried adding/substracting from those built with that method (yet), but have achieved stability after switching from the CA firewall to Microsoft's (built-in XP) firewall.

If you're seeing any Java errors in your Java Console log, that might be a clue to the problem your experiencing.


Edit:
Example of Log error:

java.lang.ArrayIndexOutOfBoundsException: -1 < 0

[hubanks]

i have a new dual processor computer with 2GB of RAM

i am only running MS Internet Explorer with Live Charts and Norton Internet Security (to protect me from viruses, etc)

Old Live Charts never would freeze

New Live Charts freezes up 3 to 5 times a day

It always runs fine for a few hours then freezes up

[j1900q]

100 % cpu usage, locks up computer

I tried running just livecharts, same deal.
Still freezes then locks up computer. CPU stuck at 100 %. This is really getting old. I have tried firefox. and IE. both freeze.

[unhappy]

Re: 100 % cpu usage, locks up computer

Originally posted by j1900q
I tried running just livecharts, same deal.
Still freezes then locks up computer. CPU stuck at 100 %. This is really getting old. I have tried firefox. and IE. both freeze.

Yes. CPU at 100% and the Internet Explorer process blocks system response until killed.

[hubanks]

what port through the firewall does live charts use?

[dannol48]

Livecharts2 was and appears to still use ports 80 and 2812.

The new release this morning shows:

=> LiveCharts, Copyright © 2000-2008, Build LC16 of 04/20/08 <=

Old release was LC15.

I'm still operating on port 2812 with at least four ancillary http/80 sessions. I believe they were incorporating http tunneling on port 80 to operate behind corporate firewalls, so I don't know if the 2812 socket is optionable or can detect a block and automatically switch. I may try some tests later or over the weekend.

I'm also using the Computer Assocates Personal Firewall this morning for pre-market test of the new release, and it appears to be working/no disconnects (so far).

[dannol48]

In follow-up to my last post......

LC2 (new release) does indeed automatically switch to HTTP/80 when port 2812 is blocked. The new release will show (lower right on Main) which port is being used.

After a restart last Friday morning from pre-market testing, I did have a failure on socket 2812 that caused a reconnect (same Java error failure previously posted). After that disconnect, the reconnect automatically switched to HTTP/80. That session remained very stable.

In order to force a permanent use of HTTP/80, I blocked the use of 2812 on the CA Firewall. That changed caused a brief attempt to connect to 2812 at session start, a timeout, and a connect to HTTP/80. That works very well for workaround on anyone experiencing a 2812 disconnect problem due to Firewall or other unknown at this point. That precludes a disruptive disconnect and any secondary chart failures that require a restart on the chart or switching symbols to recover chart data. It should also be the standard sequence observed by anyone behind a corporate firewall, i.e. it's designed for that methodology to operate as bypass.

Hope that info helps others.....

[hubanks]

i have had NO (0) lockups/freezes since the new version was released

my live charts is using port 2812

seems fine

previous to last friday when the new version came out, my live charts would lock up between 4 and 5 times a day.

thank you technical support guys for apparently fixing this problem.

[hubanks]

one last question

why does live charts default to port 2812
and not 80 (the standard web port)

is there some advantage to port 2812?

sounds like this non standard port causes some people problems.

[wireless guru]

Port 2812 was used to receive real-time data in a legacy product so we continued to use it for LiveCharts and we used Port 80 for http tunneling.

UPDATE: The new LiveCharts build was updated last week and finished today and supports HTTP tunneling plus the following fixes/enhancements:

Fix for the “100% CPU” bug which caused applet to freeze in some cases
Fix for OBV study (last bar was always 0 on a daily chart)
Fix for data export bug when all sessions are turned off
Changed the row order in data export
Chart headers state is saved now

You should see all the fixes and users behind corporate firewalls will be able to log-in to LiveCharts now.

Thanks for your patience and understanding,

John B