Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.gui > #3921 > unrolled thread

Re: Problem with Swing Ti

Started by"Roedy Green" <roedy.green@THRWHITE.remove-dii-this>
First post2011-04-27 15:47 +0000
Last post2011-04-27 15:47 +0000
Articles 9 — 4 participants

Back to article view | Back to comp.lang.java.gui

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Problem with Swing Ti "Roedy Green" <roedy.green@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
    Re: Problem with Swing Ti "ifarberov" <ifarberov@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
      Re: Problem with Swing Ti "Daniele Futtorovic" <daniele.futtorovic@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
      Re: Problem with Swing Ti "John B. Matthews" <john.b..matthews@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
        Re: Problem with Swing Ti "ifarberov" <ifarberov@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
          Re: Problem with Swing Ti "John B. Matthews" <john.b..matthews@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
            Re: Problem with Swing Ti "ifarberov" <ifarberov@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
              Re: Problem with Swing Ti "Roedy Green" <roedy.green@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
                Re: Problem with Swing Ti "John B. Matthews" <john.b..matthews@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000

#3921 — Re: Problem with Swing Ti

From"Roedy Green" <roedy.green@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
SubjectRe: Problem with Swing Ti
Message-ID<6otm94lip39r2rgltstf9au9is0mru2qqs@4ax.com>
  To: comp.lang.java.gui
On Thu, 7 Aug 2008 10:24:41 -0700 (PDT), ifarberov@lsplab.com wrote,
quoted or indirectly quoted someone who said :

> have developed a Swing client that is comprised of 8 different
>screens. T

All the Swing gui updating, all the Swing event handling, and all your
timer tasks are handled by a single thread. If any one of them takes a
long time or goes to sleep or waits for something, it will hold up the
entire assembly line.
-- 

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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]


#3923

From"ifarberov" <ifarberov@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<b469becd-b3d6-49b4-8582-bce9c9296a08@x35g2000hsb.googlegroups.com>
In reply to#3921
  To: comp.lang.java.gui
On Aug 7, 6:29 pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> On Thu, 7 Aug 2008 10:24:41 -0700 (PDT), ifarbe...@lsplab.com wrote,
> quoted or indirectly quoted someone who said :
>
> > have developed a Swing client that is comprised of 8 different
> >screens. T
>
> All the Swing gui updating, all the Swing event handling, and all your
> timer tasks are handled by a single thread. If any one of them takes a
> long time or goes to sleep or waits for something, it will hold up the
> entire assembly line.
> --
>
> Roedy Green Canadian Mind Products
> The Java Glossaryhttp://mindprod.com


The problem is that GUI remains responsive, but Timer-driven events
don't get fired for a while, and then they just resume.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]


#3925

From"Daniele Futtorovic" <daniele.futtorovic@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<g7gfj3$q75$1@registered.motzarella.org>
In reply to#3923
  To: comp.lang.java.gui
On 08/08/2008 04:11, ifarberov@lsplab.com allegedly wrote:
> The problem is that GUI remains responsive, but Timer-driven events
> don't get fired for a while, and then they just resume.

How about the network? Have you checked that?

-- 
DF.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]


#3926

From"John B. Matthews" <john.b..matthews@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<nospam-8D7069.02061508082008@aioe.org>
In reply to#3923
  To: comp.lang.java.gui
In article 
<b469becd-b3d6-49b4-8582-bce9c9296a08@x35g2000hsb.googlegroups.com>,
 ifarberov@lsplab.com wrote:

> On Aug 7, 6:29 pm, Roedy Green <see_webs...@mindprod.com.invalid>
> wrote:
> > On Thu, 7 Aug 2008 10:24:41 -0700 (PDT), ifarbe...@lsplab.com wrote,
> > quoted or indirectly quoted someone who said :
> >
> > > have developed a Swing client that is comprised of 8 different
> > >screens. T
> >
> > All the Swing gui updating, all the Swing event handling, and all your
> > timer tasks are handled by a single thread. If any one of them takes a
> > long time or goes to sleep or waits for something, it will hold up the
> > entire assembly line.
> >
> [...]
> The problem is that GUI remains responsive, but Timer-driven events
> don't get fired for a while, and then they just resume.

You might verify that the actionPerformed() method of the Timer's 
designated ActionListener is being called with the Timer's nominal 
period. Using start(), stop(), restart(), setDelay() or setRepeats() in 
a subclass are all potential culprits. How do the subclasses deal with 
network latency in the normal course? Is your network experiencing 
unusual delays, as Daniele suggests?

-- 
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]


#3931

From"ifarberov" <ifarberov@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<6a90ee4f-075a-471a-bc01-8b008e0d7954@m73g2000hsh.googlegroups.com>
In reply to#3926
  To: comp.lang.java.gui
On Aug 8, 2:06=A0am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <b469becd-b3d6-49b4-8582-bce9c9296...@x35g2000hsb.googlegroups.com>,
>
>
>
>
>
> =A0ifarbe...@lsplab.com wrote:
> > On Aug 7, 6:29 pm, Roedy Green <see_webs...@mindprod.com.invalid>
> > wrote:
> > > On Thu, 7 Aug 2008 10:24:41 -0700 (PDT), ifarbe...@lsplab.com wrote,
> > > quoted or indirectly quoted someone who said :
>
> > > > have developed a Swing client that is comprised of 8 different
> > > >screens. T
>
> > > All the Swing gui updating, all the Swing event handling, and all you=
r
> > > timer tasks are handled by a single thread. If any one of them takes =
a
> > > long time or goes to sleep or waits for something, it will hold up th=
e
> > > entire assembly line.
>
> > [...]
> > The problem is that GUI remains responsive, but Timer-driven events
> > don't get fired for a while, and then they just resume.
>
> You might verify that the actionPerformed() method of the Timer's
> designated ActionListener is being called with the Timer's nominal
> period. Using start(), stop(), restart(), setDelay() or setRepeats() in
> a subclass are all potential culprits. How do the subclasses deal with
> network latency in the normal course? Is your network experiencing
> unusual delays, as Daniele suggests?
>
> --
> John B. Matthews
> trashgod at gmail dot com
> home dot woh dot rr dot com slash jbmatthews- Hide quoted text -
>
> - Show quoted text -

This happens most often, when both client and server run on the same
machine, so network delays can be rulled out.  I would understand it
it if the whole GUI was locked - that would mean that update is taking
too long or deadlocking.  But instead it seems that Timer events just
stop firing all together.

By the way, do you guys think it's better to use one Timer for all the
screens, or one per screen, as far as performance concerned?

Thanks for all the ideas,
Inga

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]


#3932

From"John B. Matthews" <john.b..matthews@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<nospam-493790.16160708082008@web.aioe.org>
In reply to#3931
  To: comp.lang.java.gui
In article 
<6a90ee4f-075a-471a-bc01-8b008e0d7954@m73g2000hsh.googlegroups.com>,
 ifarberov@lsplab.com wrote:

> On Aug 8, 2:06aam, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > In article
> > <b469becd-b3d6-49b4-8582-bce9c9296...@x35g2000hsb.googlegroups.com>,
> >
> > aifarbe...@lsplab.com wrote:
> > > On Aug 7, 6:29 pm, Roedy Green <see_webs...@mindprod.com.invalid>
> > > wrote:
> > > > On Thu, 7 Aug 2008 10:24:41 -0700 (PDT), ifarbe...@lsplab.com wrote,
> > > > quoted or indirectly quoted someone who said :
> >
> > > > > have developed a Swing client that is comprised of 8 different
> > > > >screens. T
> >
> > > > All the Swing gui updating, all the Swing event handling, and all your
> > > > timer tasks are handled by a single thread. If any one of them takes a
> > > > long time or goes to sleep or waits for something, it will hold up the
> > > > entire assembly line.
> >
> > > [...]
> > > The problem is that GUI remains responsive, but Timer-driven events
> > > don't get fired for a while, and then they just resume.
> >
> > You might verify that the actionPerformed() method of the Timer's
> > designated ActionListener is being called with the Timer's nominal
> > period. Using start(), stop(), restart(), setDelay() or setRepeats() in
> > a subclass are all potential culprits. How do the subclasses deal with
> > network latency in the normal course? Is your network experiencing
> > unusual delays, as Daniele suggests?
>[...] 

> This happens most often, when both client and server run on the same 
> machine, so network delays can be rulled out.

This certainly suggests some kind of resource contention, and even the 
loopback interface takes time and consumes cycles.

> I would understand it it if the whole GUI was locked - that would 
> mean that update is taking too long or deadlocking.  But instead it 
> seems that Timer events just stop firing all together.

Which makes me wonder if a subclass stops the timer while waiting for 
something. If it's possible, the NetBeans IDE profiler has a nice 
threads display. As javax.swig.Timer action event handlers execute on 
the EDT, look for AWT-EventQueue-0 (or similar). I'm sure other IDEs 
have something similar.

-- 
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]


#3933

From"ifarberov" <ifarberov@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<3f05236e-f599-41ec-9ac9-2ff561d6b7b9@s50g2000hsb.googlegroups.com>
In reply to#3932
  To: comp.lang.java.gui
On Aug 8, 4:16 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <6a90ee4f-075a-471a-bc01-8b008e0d7...@m73g2000hsh.googlegroups.com>,
>
>
>
>
>
>  ifarbe...@lsplab.com wrote:
> > On Aug 8, 2:06 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > > In article
> > > <b469becd-b3d6-49b4-8582-bce9c9296...@x35g2000hsb.googlegroups.com>,
>
> > >  ifarbe...@lsplab.com wrote:
> > > > On Aug 7, 6:29 pm, Roedy Green <see_webs...@mindprod.com.invalid>
> > > > wrote:
> > > > > On Thu, 7 Aug 2008 10:24:41 -0700 (PDT), ifarbe...@lsplab.com wrote,
> > > > > quoted or indirectly quoted someone who said :
>
> > > > > > have developed a Swing client that is comprised of 8 different
> > > > > >screens. T
>
> > > > > All the Swing gui updating, all the Swing event handling, and all your
> > > > > timer tasks are handled by a single thread. If any one of them takes a
> > > > > long time or goes to sleep or waits for something, it will hold up the
> > > > > entire assembly line.
>
> > > > [...]
> > > > The problem is that GUI remains responsive, but Timer-driven events
> > > > don't get fired for a while, and then they just resume.
>
> > > You might verify that the actionPerformed() method of the Timer's
> > > designated ActionListener is being called with the Timer's nominal
> > > period. Using start(), stop(), restart(), setDelay() or setRepeats() in
> > > a subclass are all potential culprits. How do the subclasses deal with
> > > network latency in the normal course? Is your network experiencing
> > > unusual delays, as Daniele suggests?
> >[...]
> > This happens most often, when both client and server run on the same
> > machine, so network delays can be rulled out.
>
> This certainly suggests some kind of resource contention, and even the
> loopback interface takes time and consumes cycles.
>
> > I would understand it it if the whole GUI was locked - that would
> > mean that update is taking too long or deadlocking.  But instead it
> > seems that Timer events just stop firing all together.
>
> Which makes me wonder if a subclass stops the timer while waiting for
> something. If it's possible, the NetBeans IDE profiler has a nice
> threads display. As javax.swig.Timer action event handlers execute on
> the EDT, look for AWT-EventQueue-0 (or similar). I'm sure other IDEs
> have something similar.
>
> --
> John B. Matthews
> trashgod at gmail dot com
> home dot woh dot rr dot com slash jbmatthews- Hide quoted text -
>
> - Show quoted text -

After reading some of the above suggestions I have developed a new
theory of what may be going on.  It seems that if a computer clock is
adjusted backwards while swing timer is used, the timer stops firing
action events.  And as a matter of fact my program does speed up
system clock.  Once in a while the computer clock in syncronized with
the network clock, which may push my computer clock back.

Inga

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]


#3936

From"Roedy Green" <roedy.green@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<uklr9490s1qinh5qnqb9f2uc3msfh9rqh9@4ax.com>
In reply to#3933
  To: comp.lang.java.gui
On Fri, 8 Aug 2008 20:24:24 -0700 (PDT), ifarberov@lsplab.com wrote,
quoted or indirectly quoted someone who said :

>
>After reading some of the above suggestions I have developed a new
>theory of what may be going on.  It seems that if a computer clock is
>adjusted backwards while swing timer is used, the timer stops firing
>action events.  And as a matter of fact my program does speed up
>system clock.  Once in a while the computer clock in syncronized with
>the network clock, which may push my computer clock back.

I discovered this when I was writing SetClock.  See
http://mindprod.com/applet/setclock.html
http://mindprod.com/jgloss/timer.html

What could you do to recover?  In your case these adjustments would be
small.  So you could write a watchdog timer that wakes up say every 10
seconds and determines if the screw up has happened, and if so
reschedule.   The watchdog would survive since it has a long enough
interval.

It is a kludge.  

Another solution is to get a new motherboard with a more accurate
clock so it won't need adjusting.

-- 

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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]


#3939

From"John B. Matthews" <john.b..matthews@THRWHITE.remove-dii-this>
Date2011-04-27 15:47 +0000
Message-ID<nospam-EB9D26.15235309082008@web.aioe.org>
In reply to#3936
  To: comp.lang.java.gui
In article <uklr9490s1qinh5qnqb9f2uc3msfh9rqh9@4ax.com>,
 Roedy Green <see_website@mindprod.com.invalid> wrote:

[...]
> I discovered this when I was writing SetClock.  See
> http://mindprod.com/applet/setclock.html

Should that be <http://mindprod.com/jgloss/setclock.html>?

> Another solution is to get a new motherboard with a more accurate 
> clock so it won't need adjusting.

Sadly, all real clocks drift, but some drift less than others.

-- 
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.gui


csiph-web