Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

An embedded element management system.

 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First let me tell you what it is.



It's an application embeded into a telecom device. It loads java applet in an embeded web server. So one users open their web browser, the applet can be downloaded and run in client side. It builds the information into XML format and transform it via HTTP. In the device, the web server parse the XML, and invoke the Device API to execute the command.

The problem is this application can make the device crash sometimes!

I don't think it's the applet. Although I've found there are thread problems in the applet. But the applet is executed in the client side, it won't make the device crash. Could you help me to figure out where the problem is?

There are many threads in the client side. Every request is send to the server within a SwingWork thread. Also there is a thread polling the device every second. Do you think a thread pool is needed here?

I hope I describe the problem clearly. I'm still thinking where is the problem.

Thanks.
[ June 07, 2007: Message edited by: Louis Wang ]
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13058
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If this was my problem I would figure out a way to encapsulate all of the data involved with a command to the device in a java object which could be recorded and "played back." Probably all device state information that the server can see should also be recorded.

Recording all HTTP messages would also be a good idea.

You need to be able to pinpoint the exact sequence of commands that crashes the device before speculating about where the problem originates.

Bill
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic