Here is the email from customer:
I would like to file a bug and request your highest priority for
it (Important licencee bug fix.)
We are weeks away from a release on a year long development
effort, and this will hold things up. If this bug is not fixed,
we will need to back away from using RMI in our application ---
this will be major blow to our use of Java, and will have
significant negative consequences on the use of Java within AT&T.
The bug/request for extension is that there needs to be a way
that either end of a multiplexed RMI connection can be made to
drop the connection.
Here is the background for this request. Consider a client server
scenario, where the client and the server communicate using
RMI. Now, situations arise where the client is behind the
firewall, and the server is outside the firewall, and the
firewall can allow outgoing TCP/IP connections to be established.
Thus the client can open a connection, but the server may not
open a connection back to the client. Under these circumstances,
it is still possible to set up RMI between the two operating over
what is called a multiplexed connection.
This is an undocumented part of the API, but the JavaSoft team
has released details of it over the Java-rmi mailing list (see
the archives), and shown how to establish such a link. In fact,
such a link is the basis for allowing applets to call servers
using RMI. This is the only way that RMI can be made to work
through a firewall, except for the HTTP tunneling implementation
which has unaccapetable installation management and overhead
problems.
Now it appears that the duration of this multiplexed link is not
under application control. RMI has its own policy for how long
this link will remain up: viz, forever. This basically means that
multiplexed connections are unusable, because the server will not
be able to serve more than, say a thousand hits before it cannot
open a new connection (assuming the clients on the other side
have still not exted, e.g. they are browsing some other site).
What is desired is that a method be provided by which either end
of the client can force the muitplexed connection to be
dropped. A typical usage scenario is that the client "logs into"
the server after the connection is established, and then after a
while "logs out". At this stage either the client or the server
must be able to terminate the connection.
I would like to file a bug and request your highest priority for
it (Important licencee bug fix.)
We are weeks away from a release on a year long development
effort, and this will hold things up. If this bug is not fixed,
we will need to back away from using RMI in our application ---
this will be major blow to our use of Java, and will have
significant negative consequences on the use of Java within AT&T.
The bug/request for extension is that there needs to be a way
that either end of a multiplexed RMI connection can be made to
drop the connection.
Here is the background for this request. Consider a client server
scenario, where the client and the server communicate using
RMI. Now, situations arise where the client is behind the
firewall, and the server is outside the firewall, and the
firewall can allow outgoing TCP/IP connections to be established.
Thus the client can open a connection, but the server may not
open a connection back to the client. Under these circumstances,
it is still possible to set up RMI between the two operating over
what is called a multiplexed connection.
This is an undocumented part of the API, but the JavaSoft team
has released details of it over the Java-rmi mailing list (see
the archives), and shown how to establish such a link. In fact,
such a link is the basis for allowing applets to call servers
using RMI. This is the only way that RMI can be made to work
through a firewall, except for the HTTP tunneling implementation
which has unaccapetable installation management and overhead
problems.
Now it appears that the duration of this multiplexed link is not
under application control. RMI has its own policy for how long
this link will remain up: viz, forever. This basically means that
multiplexed connections are unusable, because the server will not
be able to serve more than, say a thousand hits before it cannot
open a new connection (assuming the clients on the other side
have still not exted, e.g. they are browsing some other site).
What is desired is that a method be provided by which either end
of the client can force the muitplexed connection to be
dropped. A typical usage scenario is that the client "logs into"
the server after the connection is established, and then after a
while "logs out". At this stage either the client or the server
must be able to terminate the connection.
- relates to
-
JDK-4094893 (1.x) cached connections should be freed when ServerSocket.accept/Socket create
-
- Resolved
-
-
JDK-4183204 client-side multiplexing should be disabled
-
- Resolved
-