-
Changing Threaded Socket Java App to GUI interface makes Threads behave differently
Hi everyone -
I made a Java application to test how well a multi-socket log-in authenticator
(which is a VB app.) responds to multiple hits (I guess it's kind of like
a "load tester").
For the tester application, I designed a "socketBank" class which allows
a client to specify how many sockets to test with, and also passes in a log-in
string to send to the receiving socket application. The socketBank class
creates a vector of Thread objects which each instantiate a socket class
within them. The number of threads in the vector correspond to the number
of sockets specified by the client.
When I use a non-GUI class to run the socketBank class, it behaves very well,
and all the threads connect, send and receive with the VB socket app. with
perfect results.
However, when I tried to use a Swing-based GUI class to run the socketClass,
there are some problems. The threads seem to behave erratically, and don't
receive the response from the other app. as quickly as they did with the
non-GUI version.
Also, the GUI class freezes up while the socketBank Threads are running (as
does the VB app.) The VB app. did not freeze at all when it was being connected
to by the non-GUI version.
I hope this explanation makes sense. I have puzzled over this difference
in behaviour for a long time, but I still don't have an answer.
Thanks to anyone who can enlighten me about this problem.
Sam Goldberg
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
Forum Rules
|
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL
|
Bookmarks