General questions about JFrame class and threads 1

[frag]

Hi!

This might be a pretty stupid question but I will try it anyway...

Whenever I write a Swing-based application I use a class that extends JFrame and generate all Swing-components in the cunstrutor of this class.

Could someone please explain how Java handels this? Because I would expect that the application would close after the cunstructor was processed, but instead the frame stays and will not disappear until it is told to do so (ActionEvent, dispose(), whatever...).

I want to know this because I have some problem with a SSLsocket that is losing connection over and over again and I have the suspicion that this has something to do with the Swing stuff... or the threads I use.

Example: I open a socket in the JFrame cunstructor, call a method to draw all the Swing components and show a JDialog. In the actionPerformed-method I start a thread everytime a button is clicked and in this thread I want to use the socket that was opened in the constructor... but it is closed/not available.

Is there something I have to know regarding the life cycle of sockets?

thanx in advance

frag

patrick.metz@epost.de

 

[palbano]

The first two questions that come to mind are, (1) Are you sure you have the same java.net.Socket object reference? (2) Is the other side of the connection closing?

-pete

 

[frag]

Hi palbano,

to answer your questions:

(1) I am pretty sure that I use the same object reference the whole time.

(2) The thing described above is the client side. The error comes on the server side when trying to read from the stream. So I think it's obviously that it must be an errror on the client side.


Do you know if you can have several threads using the same instance of the socket and the stream(s)? Are they thread safe? Perhapse this is my problem.... I have threads sharing socket and streams.


cheers

frag

patrick.metz@epost.de

 

[seanbo]

the life cycle of sockets shouldn't be too different than any other object. it's fine to initialise it in the constructor, just make sure you declare it to the whole class to ensure that it stays around as long as the extended jframe.

____________________________________________________
If you like a post, show you care by giving it a star.

 

[frag]

@seanbo: that is what i did... declared the socket and the streams globally and instanciated them in the constructor.

patrick.metz@epost.de

 

[palbano]

If I understand your project and reported behavior, the client would only be the source of the problem if it is closing the socket. Otherwise the problem would be in the Server.

-pete

 

[frag]

I guess that the client puts several objects on the stream (becaus of the threads I use) at the same time and the server gets problems when trying to read from this stream.

Does this sound like it would make sense?

patrick.metz@epost.de

 

[palbano]

It makes sense that it would be a problem. Sounds like your client design might need a little adjustment.

You don’t need multiple threads for writing to a socket. Unless your application has requirements for multiple threads outside of the socket communications, just use one. If you must have multiple threads then you need to synchronize writing to the socket.

I hope that makes sense, i feel a little "off" today.

-pete

 

[frag]

palbano that made definitely sense!. Without having read your post, I figured out that I synchronized the manipulation of the object I want to send but not the write and read of the streams. I changed that and I works (ok I get a NullPointerException when reading the object but this is another problem).

Thanks for helping!

patrick.metz@epost.de