[Jython-bugs] [ jython-Bugs-1744567 ] Socket hangs in 2.2RC1

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1744567, was opened at 2007-06-27 21:58
Message generated for change (Settings changed) made by cgroves
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1744567&group_id=12867

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: targeted for 2.2rc2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bob Luse (rluse)
Assigned to: Alan Kennedy (amak)
Summary: Socket hangs in 2.2RC1

Initial Comment:
Hi,

I have a case where code that works fine in 2.2B2 has problems in 2.2RC1.  I've included 3 modules and you should be able to recreate it fairly easily.  Just run the Server, and then run the Client GUI.  They are setup to run on the same machine, you will have to make sure the ports match up.  When I run this code on 2.2b2, I can hit the send button and data gets sent to the server and a response comes back.  When I run it on 2.2 RC2, the GUI hangs and the message doesn't appear to be sent.  I suspect this has to do with the thread that I am using in the Client (which ironically I did a lot of work to put in because Jython didn't have Select!)   

Let me know if you have any questions.

Bob

----------------------------------------------------------------------

Comment By: Bob Luse (rluse)
Date: 2007-06-28 17:41

Message:
Logged In: YES 
user_id=1688601
Originator: YES

OK - I have retrofitted the change to use the sockets directly on my
entire app and everything seems to be fine.  If you noticed, the server
module that I sent subclasses StreamRequestHandler from SocketServer which
uses makefile.  I had to switch this to use BaseRequestHandler so that I
could use the sockets directly on the server as well.  The problem on the
server side only manifested itself after a few sends.  I am assuming that
this is because the StreamRequestHandler code is better than mine, but I
really dont know why it doesn't happen right away like it does on my
client.  You may want to look at that as well.

Thanks for the quick help and I appreciate that you realized the
usefulness of my example .  It took me considerable amount of time to
isolate it to that level.  I realize that you are implementing a major
change and also how difficult it can be to find problems like this
sometimes.  

As for my GUI, the getContentPane requirement was removed from Java I
think when 1.5 was introduced.  So, the message that you got would make
sense if you are using 1.4.x.  It is easy to change.  For future reference
I think if you would change 

         self.layout = awt.FlowLayout()   to
         self.getContentPane().layout = awt.FlowLayout()

that it would work fine.

----------------------------------------------------------------------

Comment By: Bob Luse (rluse)
Date: 2007-06-28 15:54

Message:
Logged In: YES 
user_id=1688601
Originator: YES

Hi,

I've switched back to using send and recv and it appears to be working.  I
had just switched to using the makefile very recently.  

I am also having a problem using select, but I am not sure that it is not
user error.  You probably do not want to use this forum for my questions,
so I will send them on the dev. 

Also, was there a problem with my GUI that I sent to run the tests?  It
was just standard swing.  

----------------------------------------------------------------------

Comment By: Alan Kennedy (amak)
Date: 2007-06-28 14:44

Message:
Logged In: YES 
user_id=647684
Originator: NO

OK, I'm reasonably confident that this is a java bug, related to the
simultaneous use of input and output streams on a socket created by
java.nio. See these bug reports for further info

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4509080
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4774871

The problem is that the read and write methods of the InputStream and
OutputStream returned by the java.nio.channels.Channels class are protected
by a lock, which means that asocket cannot be read and written to at the
same time by different threads. Which is exactly what your code is trying
to do: ironic that your workaround for select breaks when select becomes
available!

I think I can code around this bug, by creating PyFiles that read and
write from Channels instead of [In|Out]putStreams, but I need to do more
research to verify that.

In the meantime, you have a few possible solutions:

1. Use select! That's what its for; now that we've got it, why not use it
:-)
2. Don't try to write and read simultaneously on the same PyFile returned
from socket.makefile(). For example, insert a delay (you can see this by
making your IncomingMessageHandler.run() method sleep for a second or two
before it reads from the socket).
3. Directly use socket send and recv methods to talk to the socket; they
are not affected by this locking problem.

Thanks for taking the time report this one. Your code made it very easy to
find the problem, which could otherwise have been very difficult to track
down.

----------------------------------------------------------------------

Comment By: Alan Kennedy (amak)
Date: 2007-06-28 13:58

Message:
Logged In: YES 
user_id=647684
Originator: NO

I use this script to recreate the problem.

#-=-=-=-=--=-=
from Client import Client

class MyCallback:

    def readyReceived(self):
        print "Callback received ready notification"

if __name__ == "__main__":
    cli = Client('localhost', 9000, MyCallback())
    cli.send()
#-=-=-=-=-=-=-=-=

When I use this script, the code hangs on trying to send to the socket.

However, the bug seems to be with the object returned from the makefile
method. When I replace your Client.send() method with this method, which
sends directly on the socket rather than through the madefile

#-=-=-=-=-=-=-=-=
    def send(self):
        print 'Enter Client send()'
#        self.fc.write("Send" + "\r\n")
        self.connection.send("Send" + "\r\n")
        print 'Exit Client send()'
#-=-=-=-=-=-=-=-=

The org.python.core.PyFile object returned from socket.makefile() seems to
be hanging on the write call.

I'm looking into what that might hang now; more soon.

----------------------------------------------------------------------

Comment By: Alan Kennedy (amak)
Date: 2007-06-28 13:52

Message:
Logged In: YES 
user_id=647684
Originator: NO

OK, I can recreate the problem.

However, I can't get your GUI client running: I get this error message.

"""
java.lang.Error: Do not use
org.python.proxies.__main__$TestRemoteConnectionGUI$0.setLayout() use
org.python.proxies.__main__$TestRemoteConnectionGUI$0.getContentPane().setLayout()
instead
"""

I'll show how I create the problem in another message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1744567&group_id=12867