[JBoss JIRA] Updated: (JBREM-480) Insure reliable tests in socket invoker for unusable socket connections.
by Tom Elrod (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-480?page=all ]
Tom Elrod updated JBREM-480:
-----------------------------
Fix Version/s: 2.2.0.CR1 (Boon)
(was: 2.2.0.Beta1 (Bluto))
> Insure reliable tests in socket invoker for unusable socket connections.
> ------------------------------------------------------------------------
>
> Key: JBREM-480
> URL: http://jira.jboss.com/jira/browse/JBREM-480
> Project: JBoss Remoting
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 2.0.0.CR1 (Boon)
> Reporter: Ron Sigal
> Assigned To: Tom Elrod
> Fix For: 2.2.0.CR1 (Boon)
>
>
> The socket invoker needs to test for unusable socket connections, on both the client and server side. There are currently two tests in place, only one of which is correct. On the client side, if the shouldCheckConnection flag is set, then MicroSocketClientInvoker.getPooledConnection() and SocketClientInvoker.getPooledConnection() will call ClientSocketWrapper.checkConnection(), which will call ObjectInputStream.readByte(), which throws an EOFException at end of file, i.e., when the remote endpoint closes. If the shouldCheckConnection flag is not set, then SocketClientInvoker.getPooledConnection() will call Socket.isConnected() on its socket, and MicroSocketClientInvoker.getPooledConnection() makes no test. In any case, Socket.isConnected() does not appear to be useful, since it seems that a Socket, once connected, never returns to a disconnected state (at least in linux and jdk 1.4). On the server side, ServerThread.acknowledge() will call ServerSocketWrapper.checkConnection(), which behaves like ClientSocketWrapper.checkConnection(), if the shouldCheckConnection flag is set.
> The problem on the client side is that if the performVersioning flag is set, a version byte will be read by calling InputStream.read(), which returns -1 at end of file instead of throwing EOFException. If an InputStream at end of file is not tested for end of file, -1 will be read and treated as an incorrect version. resulting in an Exception. There needs to be an explicit test for -1.
> On the server side, a version of -1 is set to 1, and the end of file condition is caught later. It would be simpler to test explicitly for -1.
> In any case, we need to verify that there are reliable tests in place for unusable connections. It is difficult to see how to write a unit test that creates an error condition on a socket, but there should be unit tests for client side and server side end of file conditions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months
[JBoss JIRA] Updated: (JBREM-47) Dynamic classloading
by Tom Elrod (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-47?page=all ]
Tom Elrod updated JBREM-47:
----------------------------
Fix Version/s: 2.2.0.Beta2 (Boon)
(was: 2.2.0.Beta1 (Bluto))
> Dynamic classloading
> --------------------
>
> Key: JBREM-47
> URL: http://jira.jboss.com/jira/browse/JBREM-47
> Project: JBoss Remoting
> Issue Type: Feature Request
> Components: general
> Affects Versions: 1.0.1 beta
> Reporter: Tom Elrod
> Assigned To: Tom Elrod
> Fix For: 2.2.0.Beta2 (Boon)
>
>
> Need ability for dynamic classloading to satisfy two needs. The first, is when an ejb lookup is done, and if do not have the class on the client, can download the client classes for remoting. This is much more efficient than having to serialize all these classes (as there may be many and may not even know what they are until runtime). Also, would like to add the ability for client or server to pass implementation for interfaces across the wire and if the other side does not have those classes, can load them. Once particular case when this might be needed is if using JMX sub-system, client could create custom QueryExp? implementation and pass to the server, and the server could load that class and perform the query. Will require security around this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months
[JBoss JIRA] Updated: (JBREM-124) implement APR transport
by Tom Elrod (JIRA)
[ http://jira.jboss.com/jira/browse/JBREM-124?page=all ]
Tom Elrod updated JBREM-124:
-----------------------------
Fix Version/s: 2.2.0.Beta2 (Boon)
(was: 2.2.0.Beta1 (Bluto))
> implement APR transport
> -----------------------
>
> Key: JBREM-124
> URL: http://jira.jboss.com/jira/browse/JBREM-124
> Project: JBoss Remoting
> Issue Type: Task
> Components: transport
> Affects Versions: 1.2.0 final
> Reporter: Tom Elrod
> Assigned To: Tom Elrod
> Priority: Critical
> Fix For: 2.2.0.Beta2 (Boon), 3.0.0.Alpha1 (Otter)
>
>
> Need to add support of Apache APR based transport. The APR code (from tomcat-connector project) uses native code to manage threads and sockets. The end result is a much better performance using a NIO type approach where only have threads in use for processing data off the socket. When socket is idle, the threads are released and the native code will callback to activate a thread to process the data.
> This effort has already been started in JBossRemoting on a branch called apr_transport. Will probably not be fully implemented till after 1.2.0 release.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months
[JBoss JIRA] Created: (JGRP-397) I am new to the JGroups, tcp.xml configuration on linux raise bug
by sampangi apparao (JIRA)
I am new to the JGroups, tcp.xml configuration on linux raise bug
-----------------------------------------------------------------
Key: JGRP-397
URL: http://jira.jboss.com/jira/browse/JGRP-397
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1
Environment: Linux
Reporter: sampangi apparao
Assigned To: Bela Ban
Priority: Minor
I wrote simple program with tcp.xml configuration and it implements ExtendedMessageListener, ExtendedMembershipListener and overide only the following method and remain empty
public void viewAccepted(View new_view) {
System.out.println("Received view " + new_view + '\n');
// TODO Auto-generated method stub
}
when I am executing the program my machine was not identifing with ip address. I issued a command like
java -Djgroups.bind_address=172.16.2.30 -Djgroups.tcpping.initial_hosts=172.16.2.30[7800] -Djava.net.preferIPv4Stack=true -classpath $classpath com.packetmotion.poc.SimpleTest
I am getting result like
GMS: address is 127.0.0.1:7800
Received View [127.0.0.1:7800|0] [127.0.0.1:7800]
but my machine ip is 172.16.2.30.
please provide the solution to resolve this issue
Advance thanks for your solution.
regards
Rao
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 10 months