Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: JRuby 1.5
-
Component/s: Core Classes/Modules, Windows
-
Labels:None
-
Environment:Windows XP, Jruby 1.1.0
Description
When a Drb client runs on windows it create multiple sockets and then immediately closes them. It is only the client code that does this.
When the same code was run under MRI ruby it worked fine.
# ==== Client code # require 'drb/drb' # The URI to connect to SERVER_URI="druby://localhost:8787" # Start a local DRbServer to handle callbacks. # # Not necessary for this small example, but will be required # as soon as we pass a non-marshallable object as an argument # to a dRuby call. DRb.start_service timeserver = DRbObject.new_with_uri(SERVER_URI) 100.times do sleep(1) puts timeserver.get_current_time end
# This illustrates setting up a simple client-server drb
# system. Run the server and client code in different terminals,
# starting the server code first.
#
# ==== Server code
#
require 'drb/drb'
# The URI for the server to connect to
URI="druby://localhost:8787"
class TimeServer
def get_current_time
return Time.now
end
end
# The object that handles requests on the server
FRONT_OBJECT=TimeServer.new
$SAFE = 1 # disable eval() and friends
DRb.start_service(URI, FRONT_OBJECT)
# Wait for the drb server thread to finish before exiting.
DRb.thread.join
This problem only occurs on windows and only with JRUBY running the client.
Since Drb uses Sockets , it a socket problem.
Activity
No movement on this in two years, and then a reformat makes me want to try fixing it 
It doesn't appear the JDK has changed since that thread you (Derek) posted, so more drastic measures would be necessary to fix this. Specifically, anyone wanting to fix this would need to implement their own selector for Windows that doesn't use the default pipe logic.
You would need to duplicate (and probably just copy and modify, since they're GPLed) WindowsSelectorImpl and PipeImpl from jdk/src/windows/classes/sun/nio/ch and SelectorImpl from jdk/src/share/classes/sun/nio/ch. WindowsSelectorImpl extends SelectorImpl extends java.nio.channels.spi.AbstractSelector, and uses Pipe.open to create the wakeupPipe in its constructor. The hacked version would probably construct a pipe in the same general way (if it's true that there's no other way to get a selectable stream on Windows than to open a socket), but might be configurable for a specific NIC or port range.
Given that implementation, it should be possible to modify our IO logic to use that selector rather than the standard one, and it may be possible to register a new SelectorProvider via the SPI mechanisms in the JDK.
This is obviously pretty far outside the domain of what we'd consider for JRuby, however.
It doesn't appear the JDK has changed since that thread you (Derek) posted, so more drastic measures would be necessary to fix this. Specifically, anyone wanting to fix this would need to implement their own selector for Windows that doesn't use the default pipe logic.
You would need to duplicate (and probably just copy and modify, since they're GPLed) WindowsSelectorImpl and PipeImpl from jdk/src/windows/classes/sun/nio/ch and SelectorImpl from jdk/src/share/classes/sun/nio/ch. WindowsSelectorImpl extends SelectorImpl extends java.nio.channels.spi.AbstractSelector, and uses Pipe.open to create the wakeupPipe in its constructor. The hacked version would probably construct a pipe in the same general way (if it's true that there's no other way to get a selectable stream on Windows than to open a socket), but might be configurable for a specific NIC or port range.
Given that implementation, it should be possible to modify our IO logic to use that selector rather than the standard one, and it may be possible to register a new SelectorProvider via the SPI mechanisms in the JDK.
This is obviously pretty far outside the domain of what we'd consider for JRuby, however.
Here is a succinct review of the issue. There is no workaround, other than to use a different protocol than the default JRuby DRbTCPSocket, which is NIO-based.
http://forum.java.sun.com/thread.jspa?threadID=579675&messageID=2940535