jboss-remoting-commits
June 2008
jboss-remoting-commits@lists.jboss.org
- 1 participants
- 64 discussions
JBoss Remoting SVN: r4313 - remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/timeout.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 02:05:38 -0400 (Sun, 22 Jun 2008)
New Revision: 4313
Added:
remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/timeout/ServerThreadReuseAfterTimeoutTestCase.java
Log:
JBREM-1002: New unit test.
Added: remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/timeout/ServerThreadReuseAfterTimeoutTestCase.java
===================================================================
--- remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/timeout/ServerThreadReuseAfterTimeoutTestCase.java (rev 0)
+++ remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/timeout/ServerThreadReuseAfterTimeoutTestCase.java 2008-06-22 06:05:38 UTC (rev 4313)
@@ -0,0 +1,315 @@
+/*
+* JBoss, Home of Professional Open Source
+* Copyright 2005, JBoss Inc., and individual contributors as indicated
+* by the @authors tag. See the copyright.txt in the distribution for a
+* full listing of individual contributors.
+*
+* This is free software; you can redistribute it and/or modify it
+* under the terms of the GNU Lesser General Public License as
+* published by the Free Software Foundation; either version 2.1 of
+* the License, or (at your option) any later version.
+*
+* This software is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this software; if not, write to the Free
+* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
+*/
+package org.jboss.test.remoting.transport.socket.timeout;
+
+import java.lang.reflect.Field;
+import java.net.InetAddress;
+import java.util.HashMap;
+import java.util.LinkedList;
+import java.util.Map;
+import java.util.Set;
+
+import javax.management.MBeanServer;
+
+import junit.framework.TestCase;
+
+import org.apache.log4j.ConsoleAppender;
+import org.apache.log4j.Level;
+import org.apache.log4j.Logger;
+import org.apache.log4j.PatternLayout;
+import org.jboss.logging.XLevel;
+import org.jboss.remoting.Client;
+import org.jboss.remoting.InvocationRequest;
+import org.jboss.remoting.InvokerLocator;
+import org.jboss.remoting.ServerInvocationHandler;
+import org.jboss.remoting.ServerInvoker;
+import org.jboss.remoting.callback.Callback;
+import org.jboss.remoting.callback.HandleCallbackException;
+import org.jboss.remoting.callback.InvokerCallbackHandler;
+import org.jboss.remoting.transport.Connector;
+import org.jboss.remoting.transport.PortUtil;
+import org.jboss.remoting.transport.socket.LRUPool;
+import org.jboss.remoting.transport.socket.ServerThread;
+import org.jboss.remoting.transport.socket.SocketServerInvoker;
+
+
+/**
+ *
+ * Unit test for JBREM-1002.
+ *
+ * @author <a href="ron.sigal(a)jboss.com">Ron Sigal</a>
+ * @version $Revision: 1.1 $
+ * <p>
+ * Copyright Jun 22, 2008
+ * </p>
+ */
+public class ServerThreadReuseAfterTimeoutTestCase extends TestCase
+{
+ private static Logger log = Logger.getLogger(ServerThreadReuseAfterTimeoutTestCase.class);
+
+ private static boolean firstTime = true;
+
+ protected String host;
+ protected int port;
+ protected String locatorURI;
+ protected InvokerLocator serverLocator;
+ protected Connector connector;
+ protected TestInvocationHandler invocationHandler;
+
+
+ public void setUp() throws Exception
+ {
+ if (firstTime)
+ {
+ firstTime = false;
+ Logger.getLogger("org.jboss.remoting").setLevel(XLevel.INFO);
+ Logger.getLogger("org.jboss.test.remoting").setLevel(Level.INFO);
+ String pattern = "[%d{ABSOLUTE}] [%t] %5p (%F:%L) - %m%n";
+ PatternLayout layout = new PatternLayout(pattern);
+ ConsoleAppender consoleAppender = new ConsoleAppender(layout);
+ Logger.getRootLogger().addAppender(consoleAppender);
+ }
+ }
+
+
+ public void tearDown()
+ {
+ }
+
+
+ public void testJavaSerializationDefault() throws Throwable
+ {
+ log.info("entering " + getName());
+ Map config = new HashMap();
+ doJavaSerializationTest(config);
+ log.info(getName() + " PASSES");
+ }
+
+
+ public void testJavaSerializationConfigured() throws Throwable
+ {
+ log.info("entering " + getName());
+ Map config = new HashMap();
+ config.put(ServerThread.CONTINUE_AFTER_TIMEOUT, "false");
+ doJavaSerializationTest(config);
+ log.info(getName() + " PASSES");
+ }
+
+
+ public void testJBossSerializationDefault() throws Throwable
+ {
+ log.info("entering " + getName());
+ Map config = new HashMap();
+ doJBossSerializationTest(config);
+ log.info(getName() + " PASSES");
+ }
+
+
+ public void testJBossSerializationConfigured() throws Throwable
+ {
+ log.info("entering " + getName());
+ Map config = new HashMap();
+ config.put(ServerThread.CONTINUE_AFTER_TIMEOUT, "true");
+ doJBossSerializationTest(config);
+ log.info(getName() + " PASSES");
+ }
+
+
+ public void doJavaSerializationTest(Map clientConfig) throws Throwable
+ {
+ log.info("entering " + getName());
+
+ // Start server.
+ setupServer("java");
+
+ // Create client.
+ InvokerLocator clientLocator = new InvokerLocator(locatorURI);
+ clientConfig = new HashMap();
+ clientConfig.put(InvokerLocator.FORCE_REMOTE, "true");
+ addExtraClientConfig(clientConfig);
+ Client client = new Client(clientLocator, clientConfig);
+ client.connect();
+ log.info("client is connected");
+
+ // Test connections.
+ assertEquals("abc", client.invoke("abc"));
+ log.info("connection is good");
+
+ // Get ServerThread.
+ SocketServerInvoker invoker = (SocketServerInvoker) connector.getServerInvoker();
+ Field field = SocketServerInvoker.class.getDeclaredField("clientpool");
+ field.setAccessible(true);
+ LRUPool clientpool = (LRUPool) field.get(invoker);
+ assertEquals(1, clientpool.size());
+ Set s = clientpool.getContents();
+ ServerThread serverThread1 = (ServerThread) s.iterator().next();
+
+ // Get threadpool.
+ field = SocketServerInvoker.class.getDeclaredField("threadpool");
+ field.setAccessible(true);
+ LinkedList threadpool = (LinkedList) field.get(invoker);
+ assertEquals(0, threadpool.size());
+
+ // Wait for ServerThread to time out.
+ Thread.sleep(6000);
+ for (int i = 0; i < 5; i++)
+ {
+ Thread.sleep(2000);
+ if (clientpool.size() == 0) break;
+ }
+
+ if (clientpool.size() > 0)
+ {
+ fail("expect clientpool.size() == 0");
+ }
+
+ // Verify original ServerThread was returned to threadpool.
+ assertEquals(1, threadpool.size());
+ assertEquals(serverThread1, threadpool.iterator().next());
+
+ // Make another invocation and verify ServerThread was reused.
+ client.invoke("xyz");
+ assertEquals(1, clientpool.size());
+ s = clientpool.getContents();
+ ServerThread serverThread2 = (ServerThread) s.iterator().next();
+ assertEquals(serverThread1, serverThread2);
+
+ client.disconnect();
+ shutdownServer();
+ log.info(getName() + " PASSES");
+ }
+
+
+ public void doJBossSerializationTest(Map clientConfig) throws Throwable
+ {
+ log.info("entering " + getName());
+
+ // Start server.
+ setupServer("jboss");
+
+ // Create client.
+ InvokerLocator clientLocator = new InvokerLocator(locatorURI);
+ clientConfig = new HashMap();
+ clientConfig.put(InvokerLocator.FORCE_REMOTE, "true");
+ addExtraClientConfig(clientConfig);
+ Client client = new Client(clientLocator, clientConfig);
+ client.connect();
+ log.info("client is connected");
+
+ // Test connections.
+ assertEquals("abc", client.invoke("abc"));
+ log.info("connection is good");
+
+ // Get clientpool and ServerThread.
+ SocketServerInvoker invoker = (SocketServerInvoker) connector.getServerInvoker();
+ Field field = SocketServerInvoker.class.getDeclaredField("clientpool");
+ field.setAccessible(true);
+ LRUPool clientpool = (LRUPool) field.get(invoker);
+ assertEquals(1, clientpool.size());
+ Set clientpoolContents = clientpool.getContents();
+ ServerThread serverThread1 = (ServerThread) clientpoolContents.iterator().next();
+
+ // Get threadpool.
+ field = SocketServerInvoker.class.getDeclaredField("threadpool");
+ field.setAccessible(true);
+ LinkedList threadpool = (LinkedList) field.get(invoker);
+ assertEquals(0, threadpool.size());
+
+ // Wait for ServerThread to time out.
+ Thread.sleep(8000);
+
+ // Verify original ServerThread remains in clientpool.
+ assertEquals(0, threadpool.size());
+ assertEquals(1, clientpool.size());
+ clientpoolContents = clientpool.getContents();
+ assertEquals(serverThread1, clientpoolContents.iterator().next());
+
+ // Make another invocation and verify ServerThread was reused.
+ client.invoke("xyz");
+ assertEquals(1, clientpool.size());
+ clientpoolContents = clientpool.getContents();
+ ServerThread serverThread2 = (ServerThread) clientpoolContents.iterator().next();
+ assertEquals(serverThread1, serverThread2);
+
+ client.disconnect();
+ shutdownServer();
+ log.info(getName() + " PASSES");
+ }
+
+
+ protected String getTransport()
+ {
+ return "socket";
+ }
+
+
+ protected void addExtraClientConfig(Map config) {}
+ protected void addExtraServerConfig(Map config) {}
+
+
+ protected void setupServer(String serializationType) throws Exception
+ {
+ host = InetAddress.getLocalHost().getHostAddress();
+ port = PortUtil.findFreePort(host);
+ locatorURI = getTransport() + "://" + host + ":" + port + "/?timeout=4000";
+ locatorURI += "&serializationtype=" + serializationType;
+ serverLocator = new InvokerLocator(locatorURI);
+ log.info("Starting remoting server with locator uri of: " + locatorURI);
+ HashMap config = new HashMap();
+ config.put(InvokerLocator.FORCE_REMOTE, "true");
+ addExtraServerConfig(config);
+ connector = new Connector(serverLocator, config);
+ connector.create();
+ invocationHandler = new TestInvocationHandler();
+ connector.addInvocationHandler("test", invocationHandler);
+ connector.start();
+ }
+
+
+ protected void shutdownServer() throws Exception
+ {
+ if (connector != null)
+ connector.stop();
+ }
+
+
+ static class TestInvocationHandler implements ServerInvocationHandler
+ {
+ public void addListener(InvokerCallbackHandler callbackHandler) {}
+ public Object invoke(final InvocationRequest invocation) throws Throwable
+ {
+ return invocation.getParameter();
+ }
+ public void removeListener(InvokerCallbackHandler callbackHandler) {}
+ public void setMBeanServer(MBeanServer server) {}
+ public void setInvoker(ServerInvoker invoker) {}
+ }
+
+
+ static class TestCallbackHandler implements InvokerCallbackHandler
+ {
+ public void handleCallback(Callback callback) throws HandleCallbackException
+ {
+ log.info("received callback");
+ }
+ }
+}
\ No newline at end of file
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4312 - remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 02:04:12 -0400 (Sun, 22 Jun 2008)
New Revision: 4312
Modified:
remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java
Log:
JBREM-1003: Updated javadoc.
Modified: remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java
===================================================================
--- remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java 2008-06-22 06:03:04 UTC (rev 4311)
+++ remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java 2008-06-22 06:04:12 UTC (rev 4312)
@@ -32,7 +32,7 @@
/**
*
- * Unit test for
+ * Unit test for JBREM-1003.
*
* @author <a href="ron.sigal(a)jboss.com">Ron Sigal</a>
* @version $Revision: 1.1 $
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4311 - remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 02:03:04 -0400 (Sun, 22 Jun 2008)
New Revision: 4311
Added:
remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java
Log:
JBREM-1003: New unit test.
Added: remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java
===================================================================
--- remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java (rev 0)
+++ remoting2/branches/2.2/src/tests/org/jboss/test/remoting/ipv6/PercentEncodingTestCase.java 2008-06-22 06:03:04 UTC (rev 4311)
@@ -0,0 +1,92 @@
+/*
+* JBoss, Home of Professional Open Source
+* Copyright 2005, JBoss Inc., and individual contributors as indicated
+* by the @authors tag. See the copyright.txt in the distribution for a
+* full listing of individual contributors.
+*
+* This is free software; you can redistribute it and/or modify it
+* under the terms of the GNU Lesser General Public License as
+* published by the Free Software Foundation; either version 2.1 of
+* the License, or (at your option) any later version.
+*
+* This software is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this software; if not, write to the Free
+* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
+*/
+package org.jboss.test.remoting.ipv6;
+
+import junit.framework.TestCase;
+
+import org.apache.log4j.ConsoleAppender;
+import org.apache.log4j.Level;
+import org.apache.log4j.Logger;
+import org.apache.log4j.PatternLayout;
+import org.jboss.remoting.InvokerLocator;
+
+
+/**
+ *
+ * Unit test for
+ *
+ * @author <a href="ron.sigal(a)jboss.com">Ron Sigal</a>
+ * @version $Revision: 1.1 $
+ * <p>
+ * Copyright Jan 23, 2008
+ * </p>
+ */
+public class PercentEncodingTestCase extends TestCase
+{
+ private static Logger log = Logger.getLogger(PercentEncodingTestCase.class);
+ private static boolean firstTime = true;
+
+
+ public void setUp() throws Exception
+ {
+ if (firstTime)
+ {
+ firstTime = false;
+ Logger.getLogger("org.jboss.remoting").setLevel(Level.INFO);
+ Logger.getLogger("org.jboss.test.remoting").setLevel(Level.INFO);
+ String pattern = "[%d{ABSOLUTE}] [%t] %5p (%F:%L) - %m%n";
+ PatternLayout layout = new PatternLayout(pattern);
+ ConsoleAppender consoleAppender = new ConsoleAppender(layout);
+ Logger.getRootLogger().addAppender(consoleAppender);
+ log.info("java.version: " + System.getProperty("java.version"));
+ }
+ }
+
+
+ public void tearDown()
+ {
+ }
+
+
+ public void testPercentEncoding() throws Throwable
+ {
+ log.info("entering " + getName());
+
+ String version = System.getProperty("java.version");
+ if (version.startsWith("1.4"))
+ {
+ log.info("java version is " + version + ". Skipping test");
+ }
+ else
+ {
+ String locatorURI = "socket://[fe80::205:9aff:fe3c:7800%7]:7777/";
+ InvokerLocator locator = new InvokerLocator(locatorURI);
+ assertEquals(locatorURI, locator.getLocatorURI());
+
+ locatorURI = "socket://multihome/?homes=[fe80::205:9aff:fe3c:7800%7]:7777![fe80::214:22ff:feef:68bb%4]:8888";
+ locator = new InvokerLocator(locatorURI);
+ assertEquals(locatorURI, locator.getLocatorURI());
+ }
+ log.info(getName() + " PASSES");
+
+ }
+}
\ No newline at end of file
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4310 - remoting2/branches/2.2/src/main/org/jboss/remoting.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 02:02:19 -0400 (Sun, 22 Jun 2008)
New Revision: 4310
Modified:
remoting2/branches/2.2/src/main/org/jboss/remoting/InvokerLocator.java
Log:
JBREM-1003: Added code to encode and decode "%" character.
Modified: remoting2/branches/2.2/src/main/org/jboss/remoting/InvokerLocator.java
===================================================================
--- remoting2/branches/2.2/src/main/org/jboss/remoting/InvokerLocator.java 2008-06-22 05:55:53 UTC (rev 4309)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/InvokerLocator.java 2008-06-22 06:02:19 UTC (rev 4310)
@@ -306,12 +306,12 @@
{
try
{
- URI uri = new URI(uriString);
+ URI uri = new URI(encodePercent(uriString));
protocol = uri.getScheme();
- host = resolveHost(uri.getHost());
+ host = decodePercent(resolveHost(uri.getHost()));
port = uri.getPort();
path = uri.getPath();
- query = uri.getQuery();
+ query = decodePercent(uri.getQuery());
}
catch (URISyntaxException e)
{
@@ -581,5 +581,34 @@
return serializationTypeLocal;
}
-
+ protected static String encodePercent(String s)
+ {
+ if (s == null) return null;
+ StringTokenizer st = new StringTokenizer(s, "%");
+ StringBuffer sb = new StringBuffer();
+ int limit = st.countTokens() - 1;
+ for (int i = 0; i < limit; i++)
+ {
+ String token = st.nextToken();
+ sb.append(token).append("%25");
+ }
+ sb.append(st.nextToken());
+ return sb.toString();
+ }
+
+ protected static String decodePercent(String s)
+ {
+ if (s == null) return null;
+ StringBuffer sb = new StringBuffer();
+ int fromIndex = 0;
+ int index = s.indexOf("%25", fromIndex);
+ while (index >= 0)
+ {
+ sb.append(s.substring(fromIndex, index)).append('%');
+ fromIndex = index + 3;
+ index = s.indexOf("%25", fromIndex);
+ }
+ sb.append(s.substring(fromIndex));
+ return sb.toString();
+ }
}
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4309 - remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 01:55:53 -0400 (Sun, 22 Jun 2008)
New Revision: 4309
Modified:
remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/ServerThread.java
Log:
JBREM-1002: Introduced CONTINUE_AFTER_TIMEOUT parameter.
Modified: remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/ServerThread.java
===================================================================
--- remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/ServerThread.java 2008-06-22 05:30:30 UTC (rev 4308)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/ServerThread.java 2008-06-22 05:55:53 UTC (rev 4309)
@@ -36,6 +36,7 @@
import org.jboss.remoting.marshal.UnMarshaller;
import org.jboss.remoting.marshal.VersionedMarshaller;
import org.jboss.remoting.marshal.VersionedUnMarshaller;
+import org.jboss.serial.io.JBossObjectInputStream;
import java.io.EOFException;
import java.io.IOException;
@@ -72,7 +73,11 @@
public class ServerThread extends Thread
{
// Constants ------------------------------------------------------------------------------------
-
+
+ /** Key used to determine if thread should return to threadpool after
+ * SocketTimeoutException */
+ public static final String CONTINUE_AFTER_TIMEOUT = "continueAfterTimeout";
+
final static private Logger log = Logger.getLogger(ServerThread.class);
// Static ---------------------------------------------------------------------------------------
@@ -118,6 +123,8 @@
// Will indicate when the last request has been processed (used in determining idle
// connection/thread timeout)
private long lastRequestHandledTimestamp = System.currentTimeMillis();
+
+ private boolean reuseAfterTimeout;
// Constructors ---------------------------------------------------------------------------------
@@ -368,6 +375,32 @@
socketWrapper =
createServerSocketWrapper(socket, timeout, invoker.getLocator().getParameters());
+ boolean valueSet = false;
+ Map configMap = invoker.getConfiguration();
+ Object o = configMap.get(CONTINUE_AFTER_TIMEOUT);
+ if (o != null)
+ {
+ try
+ {
+ reuseAfterTimeout = Boolean.valueOf((String)o).booleanValue();
+ valueSet = true;
+ log.debug(this + " setting reuseAfterTimeout to " + reuseAfterTimeout);
+ }
+ catch (Exception e)
+ {
+ log.warn(this + " could not convert " + CONTINUE_AFTER_TIMEOUT +
+ " value of " + o + " to a boolean value");
+ }
+ }
+
+ if (!valueSet)
+ {
+ if (socketWrapper.getInputStream() instanceof JBossObjectInputStream)
+ {
+ reuseAfterTimeout = true;
+ }
+ }
+
// Always do first one without an ACK because its not needed
if(trace) { log.trace("processing first invocation without acknowledging"); }
processInvocation(socketWrapper);
@@ -403,6 +436,9 @@
log.trace(ste);
}
}
+
+ if (!reuseAfterTimeout)
+ running = false;
}
catch (InterruptedIOException e)
{
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4308 - remoting2/branches/2.2/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 01:30:30 -0400 (Sun, 22 Jun 2008)
New Revision: 4308
Modified:
remoting2/branches/2.2/docs/guide/en/master.xml
Log:
JBREM-1001: Updated for 2.2.2.SP8.
Modified: remoting2/branches/2.2/docs/guide/en/master.xml
===================================================================
--- remoting2/branches/2.2/docs/guide/en/master.xml 2008-06-22 05:26:23 UTC (rev 4307)
+++ remoting2/branches/2.2/docs/guide/en/master.xml 2008-06-22 05:30:30 UTC (rev 4308)
@@ -22,9 +22,9 @@
<bookinfo>
<title>JBoss Remoting Guide</title>
- <subtitle>JBoss Remoting version 2.2.0.GA</subtitle>
+ <subtitle>JBoss Remoting version 2.2.2.SP8</subtitle>
- <releaseinfo>March 19, 2007</releaseinfo>
+ <releaseinfo>June 22, 2008</releaseinfo>
<mediaobject>
<imageobject>
@@ -33,7 +33,7 @@
</mediaobject>
<copyright>
- <year>2007 JBoss, a division of Red Hat</year>
+ <year>2008 JBoss, a division of Red Hat</year>
<holder>.</holder>
</copyright>
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4307 - remoting2/branches/2.2/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 01:26:23 -0400 (Sun, 22 Jun 2008)
New Revision: 4307
Modified:
remoting2/branches/2.2/docs/guide/en/chap8.xml
Log:
JBREM-1001: Updated for 2.2.2.SP8.
Modified: remoting2/branches/2.2/docs/guide/en/chap8.xml
===================================================================
--- remoting2/branches/2.2/docs/guide/en/chap8.xml 2008-06-22 05:25:27 UTC (rev 4306)
+++ remoting2/branches/2.2/docs/guide/en/chap8.xml 2008-06-22 05:26:23 UTC (rev 4307)
@@ -1,128 +1,279 @@
<?xml version="1.0" encoding="UTF-8"?>
-<chapter id="chapter-connection-failure" xreflabel="Connection Exception
- Listeners and Leasing">
- <title>Connection Exception Listeners and Leasing</title>
+<chapter id="chapter-connection-failure" xreflabel="Network Connection Monitoring">
+ <title>Network Connection Monitoring</title>
+
+ <para>Remoting has two mechanisms for monitoring the health of estabilished
+ connections, which inform listeners on the client and server sides when a
+ possible connection failure has been detected.</para>
+
+ <section>
+ <title>Client side monitoring</title>
- <bridgehead>Client side</bridgehead>
+ <para>On the client side, an
+ <classname>org.jboss.remoting.ConnectionValidator</classname> periodically
+ sends a PING message to the server and reports a failure if the response
+ does not arrive within a specified timeout period. The PING is sent on one
+ thread, and another thread determines if the response arrives in time.
+ Separating these two activities allows Remoting to detect a failure
+ regardless of the cause of the failure.</para>
+
+ <para>The creation of the <classname>ConnectionValidator</classname> is the
+ responsibility of the <classname>org.jboss.remoting.Client</classname>
+ class. All the application code needs to do is to register an implementation
+ of the <code>org.jboss.remoting.ConnectionListener</code> interface, which
+ has only one method:</para>
+
+ <programlisting>public void handleConnectionException(Throwable throwable, Client client);</programlisting>
+
+ <para>What actions the <classname>ConnectionListener</classname> chooses to
+ take are up to the application, but disconnecting the
+ <classname>Client</classname> might be a reasonable strategy.</para>
+
+ <para>The <classname>Client</classname> class has three methods for
+ registering a <classname>ConnectionListener</classname>:</para>
+
+ <programlisting>
+ public void addConnectionListener(ConnectionListener listener);
+ public void addConnectionListener(ConnectionListener listener, int pingPeriod);
+ public void addConnectionListener(ConnectionListener listener, Map metadata);
+ </programlisting>
- <para>It is possible to register a listener with the remoting client to
- receive callbacks when a connection failure to a remoting server is
- detected, even when the client is idle.</para>
+ <para>The second method supports configuring the frequency of PING messages,
+ and the third method supports more general configuration of the
+ <classname>ConnectionValidator</classname>. Note that a given
+ <classname>Client</classname> maintains a single
+ <classname>ConnectionValidator</classname>, so the parameters in the
+ metadata map are applied only on the first call to
+ <methodname>Client.addConnectionListener()</methodname>. The following
+ parameters are supported by <classname>ConnectionValidator</classname>,
+ which is where the parameter names are defined:</para>
+
+ <para><emphasis role="bold">VALIDATOR_PING_PERIOD</emphasis> (actual value
+ "validatorPingPeriod") - specifies the time, in milliseconds, that elapses
+ between the sending of PING messages to the server. The default value is
+ 2000.</para>
+
+ <para><emphasis role="bold">VALIDATOR_PING_TIMEOUT</emphasis> (actual value
+ "validatorPingTimeout") - specifies the time, in milliseconds, allowed for
+ arrival of a response to a PING message. The default value is 1000.</para>
+
+ <para>For more configuration parameters, see <xref
+ linkend="section-interactions"/>.</para>
+
+ <para>Note, also, that <classname>ConnectionValidator</classname> creates a
+ client invoker to sends the PING messages, and it passes the metadata map to
+ configure the client invoker.</para>
+
+ </section>
- <para>The only requirement is to implement the
- <code>org.jboss.remoting.ConnectionListener</code> interface, which has only
- one method:</para>
-
- <programlisting>public void handleConnectionException(Throwable throwable, Client client)</programlisting>
-
- <para>Then call the <code>addConnectionListener(ConnectionListener
- listener)</code> method on the Client class and pass your listener instance.
- Can also call <code>addConnectionListener(ConnectionListener listener, int
- pingPeriod)</code> if want to specify how frequently wish to ping
- server.</para>
-
- <para>Currently, the Client will use the
- <code>org.jboss.remoting.ConnectionValidator</code> class to handle the
- detection of connection failures. This is done by pinging the server
- periodically (defaults to every 2 seconds). If there is a failure during
- this ping, the exception and the Client will be passed to the
- listener.</para>
-
- <bridgehead>Server side</bridgehead>
-
- <para>A remoting server also has the capability to detect when a client is no
- longer available. This is done by estabilishing a lease with the remoting
- clients that connect to a server.</para>
-
- <para>To turn on server side connection failure detection of remoting clients,
- will need to satisfy two criteria. The first is that the client lease period
- is set and is a value greater than 0. The value is represented in
- milliseconds. The client lease period can be set by either the
- 'clientLeasePeriod' attribute within the Connector configuration or by calling
- the:<programlisting>public void setLeasePeriod(long
- leasePeriodValue)</programlisting>method within Connector. The second
- criterion is that an implementation of the
- <code>org.jboss.remoting.ConnectionListener</code> interface is added as a
- connection listener to the Connector, via the method:<programlisting>public
- void addConnectionListener(ConnectionListener listener)</programlisting>Note,
- there is no way to set the connection listener via xml based configuration for
- the Connector. Once both criteria are met, the remoting server will turn on
- client leasing.</para>
-
- <para>The ConnectionListener will be notified of both client failures and
- client disconnects via the handleConnectionException() method. If the client
- failed, meaning its lease was not renewed within configured time period, the
- first parameter to the handleConnectionException() method will be null. If the
- client disconnected in a regular manner, the first parameter to the
- handleConnectionException() method will be of type
- ClientDisconnectedException (which indicates a normal termination). Note,
- the client's lease will be renewed on the server with any and every
- invocation made on the server from the client, whether it be a normal
- invocation or a ping from the client internally.</para>
-
- <para>The actual lease window established on the server side is dynamic
- based the rate at which the client updates its lease. In particular, the
- lease window will always be set to lease period * 2 for any lease that does
- not have a lease update duration that is longer than 75% of the lease window
- (meaning if set lease period to 10 seconds and always update that lease in
- less then 7.5 seconds, the lease period will always remain 10 seconds). If the
- update duration is greater than 75% of the lease window, the lease window will
- be reset to the lease duration X 2 (meaning if set lease period to 10 seconds
- and update that lease in 8 seconds, the new lease window will be set to 16
- seconds). Also, the lease will not immediately expire on the first lease
- timeout (meaning did not get an update within the lease window). It takes two
- consecutive timeouts before a lease will expire and a notification for client
- connection failure is fired. This essentially means that the time it will take
- before a connection listener is notified of a client connection failure will
- be at least 4 X lease period (no exceptions).</para>
-
- <para>By default, the client is not configured to do client leasing. This
- means if want to allow client to do leasing, will need to either set invoker
- locator parameter of 'leasing' to true or include configuration entry with key
- of 'enableLease' and value of true to the map passed when creating a Client
- instance. This does not mean that client will lease for sure, but will
- indicate the client should call on the server to see if the server has
- activated leasing and get the leasing period desired by the server. If leasing
- turned on within the client can also override the lease period it
- will use, ignoring the one sent by the server, by setting 'lease_period'
- parameter in the invoker locator parameters to millisecond value. Also worth
- noting is that if the client and server are local, meaning running within the
- jvm, leasing (and thus connection notification) will not be activated, even if
- is configured to do so.</para>
-
- <para>If leasing is turned on within the client side, there is no API or
- configuration changes needed, unless want to override as mentioned previously.
- When the client initially connects to the server, it will check to see if
- client leasing is turned on by the server. If it is, it will internally start
- pinging periodically to the server to maintain the lease. When the client
- disconnects, it will internally send message to the server to stop monitoring
- lease for this client. Therefore, it is <emphasis
- role="bold">IMPORTANT</emphasis> that disconnect is called on the client when
- done using it. Otherwise, the client will continue to make its ping call on
- the server to keep its lease current.</para>
-
- <para>The client can also provide extra metadata the will be communicated to
- the connection listener in case of failure by supplying a metadata Map to the
- Client constructor. This map will be included in the Client instance passed to
- the connection listener (via the handleConnectionException() method) via the
- Client's getConfiguration() method.</para>
-
- <para>From the server side, there are two ways in which to disable leasing
- (i.e. turn leasing off). The first is to call:</para>
-
- <programlisting>public void removeConnectionListener(ConnectionListener listener)</programlisting>
-
- <para>and remove all the registered ConnectionListeners. Once the last one
- has been removed, leasing will be disabled and all the current leasing
- sessions will be terminated. The other way is to call:</para>
-
- <programlisting>public void setLeasePeriod(long leasePeriodValue)</programlisting>
-
- <para>and pass a value less than zero. This will disable leasing, preventing
- any new leases to be established but will allow current leasing sessions to
- continue.</para>
-
- <para>For examples of how to use server side connection listeners, reference
- org.jboss.test.remoting.lease.LeaseTestServer and
- org.jboss.test.remoting.lease.LeaseTestClient.</para>
+ <section id="section-server-side" xreflabel="Server side monitoring">
+ <title>Server side monitoring</title>
+
+ <para>A remoting server also has the capability to detect when a client is
+ no longer available. This is done by estabilishing a lease with the remoting
+ clients that connect to a server. On the client side, an
+ <classname>org.jboss.remoting.LeasePinger</classname> periodically sends
+ PING messages to the server, and on the server side an
+ <classname>org.jboss.remoting.Lease</classname> informs registered listeners
+ if the PING doesn't arrive withing the specified timeout period.</para>
+
+ <para><emphasis role="bold">Server side activation.</emphasis> To turn on
+ server side connection failure detection of remoting clients, it is
+ necessary to satisfy two criteria. The first is that the client lease period
+ is set and is a value greater than 0. The value is represented in
+ milliseconds. The client lease period can be set by either the
+ 'clientLeasePeriod' attribute within the Connector configuration or by
+ calling the <classname>Connector</classname> method</para>
+
+ <programlisting>public void setLeasePeriod(long leasePeriodValue);</programlisting>
+
+ <para>The second
+ criterion is that an implementation of the
+ <code>org.jboss.remoting.ConnectionListener</code> interface is added as a
+ connection listener to the Connector, via the method</para>
+
+ <programlisting>public void addConnectionListener(ConnectionListener listener)</programlisting>
+
+ <para> Once both criteria are met, the remoting server will turn on client
+ leasing.</para>
+
+ <para>Note that there is no way to register a
+ <classname>ConnectionListener</classname> via xml based configuration for
+ the <classname>Connector</classname>.</para>
+
+ <para>The ConnectionListener will be notified of both client failures and
+ client disconnects via the handleConnectionException() method. If the client
+ failed, meaning its lease was not renewed within configured time period, the
+ first parameter to the handleConnectionException() method will be null. If
+ the client disconnected in a regular manner, the first parameter to the
+ handleConnectionException() method will be of type
+ ClientDisconnectedException (which indicates a normal termination). Note,
+ the client's lease will be renewed on the server with any and every
+ invocation made on the server from the client, whether it be a normal
+ invocation or a ping from the client internally.</para>
+
+ <para>The actual lease window established on the server side is dynamic
+ based the rate at which the client updates its lease. In particular, the
+ lease window will always be set to lease period * 2 for any lease that does
+ not have a lease update duration that is longer than 75% of the lease window
+ (meaning if set lease period to 10 seconds and always update that lease in
+ less then 7.5 seconds, the lease period will always remain 10 seconds). If
+ the update duration is greater than 75% of the lease window, the lease
+ window will be reset to the lease duration X 2 (meaning if set lease period
+ to 10 seconds and update that lease in 8 seconds, the new lease window will
+ be set to 16 seconds). Also, the lease will not immediately expire on the
+ first lease timeout (meaning did not get an update within the lease window).
+ It takes two consecutive timeouts before a lease will expire and a
+ notification for client connection failure is fired. This essentially means
+ that the time it will take before a connection listener is notified of a
+ client connection failure will be at least 4 X lease period (no
+ exceptions).</para>
+
+ <para><emphasis role="bold">Client side activation.</emphasis> By default,
+ the client is not configured to do client leasing. To allow a client to do
+ leasing, either set the parameter "leasing" to "true" in the
+ <classname>InvokerLocator</classname> or set the parameter
+ <code>Client.ENABLE_LEASE</code> (actual value "enableLease") to true in the
+ <classname>InvokerLocator</classname> or in the
+ <classname>Client</classname> configuration map. [The use of
+ <code>Client.ENABLE_LEASE</code> is recommended.] This does not mean that
+ client will lease for sure, but will indicate the client should call on the
+ server to see if the server has activated leasing and get the leasing period
+ suggested by the server. It is possible to override the suggested lease
+ period by setting the parameter
+ <code>org.jboss.remoting.InvokerLocator.CLIENT_LEASE_PERIOD</code> (actual
+ value "lease_period") to a value greater than 0 and less than the value
+ suggested by the server. <emphasis role="bold">Note. </emphasis>If the
+ client and server are local, meaning running within the JVM, leasing (and
+ thus connection notification) will not be activated, even if is configured
+ to do so.</para>
+
+ <para>If leasing is turned on within the client side, there is no API or
+ configuration changes needed, unless want to override as mentioned
+ previously. When the client initially connects to the server, it will check
+ to see if client leasing is turned on by the server. If it is, it will
+ internally start pinging periodically to the server to maintain the lease.
+ When the client disconnects, it will internally send message to the server
+ to stop monitoring lease for this client. Therefore, it is <emphasis
+ role="bold">IMPORTANT</emphasis> that disconnect is called on the client
+ when done using it. Otherwise, the client will continue to make its ping
+ call on the server to keep its lease current.</para>
+
+ <para>The client can also provide extra metadata that will be communicated to
+ the connection listener in case of failure by supplying a metadata Map to
+ the Client constructor. This map will be included in the Client instance
+ passed to the connection listener (via the handleConnectionException()
+ method) via the Client's getConfiguration() method.</para>
+
+ <para>From the server side, there are two ways in which to disable leasing
+ (i.e. turn leasing off). The first is to call:</para>
+
+ <programlisting>public void removeConnectionListener(ConnectionListener listener)</programlisting>
+
+ <para>and remove all the registered ConnectionListeners. Once the last one
+ has been removed, leasing will be disabled and all the current leasing
+ sessions will be terminated. The other way is to call:</para>
+
+ <programlisting>public void setLeasePeriod(long leasePeriodValue)</programlisting>
+
+ <para>and pass a value less than zero. This will disable leasing, preventing
+ any new leases to be established but will allow current leasing sessions to
+ continue.</para>
+
+ <para>The following parameter is relevant to leasing configuration on the server side:</para>
+
+ <para><emphasis
+ role="bold"><code>org.jboss.remoting.ServerInvoker.CLIENT_LEASE_PERIOD</code></emphasis>
+ (actual value "clientLeasePeriod") - specifies the timeout period used by
+ the server to determine if a PING is late. The default value is "5000",
+ which indicates that leasing will be activated if an
+ <classname>org.jboss.remoting.ConnectionListener</classname> is registered
+ with the server. This is also the suggested lease period returned by the
+ server when the client inquires if leasing is activated.</para>
+
+ <para>The following parameters are relevant to leasing configuration on the client side:</para>
+
+ <para><emphasis
+ role="bold"><code>org.jboss.remoting.Client.ENABLE_LEASE</code></emphasis>
+ (actual value "enableLease") - if set to "true", will lead
+ <classname>org.jboss.remoting.Client</classname> to attempt to set up a
+ lease with the server, if leasing is activated on the server.</para>
+
+ <para><emphasis
+ role="bold"><code>org.jboss.remoting.InvokerLocator.CLIENT_LEASE</code></emphasis>
+ (actual value "leasing") - if set to "true" in the
+ <classname>InvokerLocator</classname>, will lead
+ <classname>org.jboss.remoting.Client</classname> to attempt to set up a
+ lease with the server, if leasing is activated on the server. It is
+ suggested that this parameter be avoided, in favor of
+ <code>Client.ENABLE_LEASE</code>.</para>
+
+ <para><emphasis
+ role="bold"><code>org.jboss.remoting.InvokerLocator.CLIENT_LEASE_PERIOD</code></emphasis>
+ (actual value "lease_period") - if set to a value greater than 0 and less
+ than the suggested lease period returned by the server, will be used to
+ determine the time between PING messages sent by
+ <classname>LeasePinger</classname>.</para>
+
+ <para><emphasis
+ role="bold"><code>org.jboss.remoting.LeasePinger.LEASE_PINGER_TIMEOUT</code></emphasis>
+ (actual value "leasePingerTimeout") - specifies the per invocation timeout
+ value use by <classname>LeasePinger</classname> when it sends PING messages.
+ In the absence of a configured value, the timeout value used by the
+ <classname>Client</classname> that created the
+ <classname>LeasePinger</classname> will be used.</para>
+
+ <para>For examples of how to use server side connection listeners, reference
+ org.jboss.test.remoting.lease.LeaseTestServer and
+ org.jboss.test.remoting.lease.LeaseTestClient.</para>
+
+ </section>
+
+ <section id="section-interactions"
+ xreflabel="Interactions between client side and server side connection monitoring">
+
+ <title>Interactions between client side and server side connection monitoring</title>
+
+ <para>As of Remoting release 2.2.2.SP7, the client side and server side connection
+ monitoring mechanisms can be, and by default are, more closely related, in
+ two ways.</para>
+
+ <orderedlist>
+ <listitem> If the parameter
+ <code>org.jboss.remoting.ConnectionValidator.TIE_TO_LEASE</code> (actual
+ value "tieToLease") is set to true, then, when the server receives a PING
+ message from an
+ <classname>org.jboss.remoting.ConnectionValidator</classname>, it will
+ return a boolean value that indicates whether a lease currently exists
+ for the connection being monitored. If leasing is activated on the client
+ and server side, then a value of "false" indicates that the lease has
+ failed, and the <classname>ConnectionValidator</classname> will treat a
+ returned value of "false" the same as a timeout; that is, it will notifiy
+ listeners of a connection failure. The default value of this parameter is
+ "true". <emphasis role="bold">Note. </emphasis>If leasing is not
+ activated on the client side, then this parameter has no
+ effect.</listitem>
+
+ <listitem><para>If the parameter
+ <code>org.jboss.remoting.ConnectionValidator.STOP_LEASE_ON_FAILURE</code>
+ (actual value "stopLeaseOnFailure") is set to true, then, upon detecting
+ a connection failure, <classname>ConnectionValidator</classname> will
+ stop the <classname>LeasePinger</classname>, if any, pinging a lease on
+ the same connection. The default value is "true".</para> </listitem>
+
+ </orderedlist>
+
+ <para><emphasis role="bold">TIE_TO_LEASE</emphasis> (actual value
+ "tieToLease") - specifies whether <classname>ConnectionValidator</classname>
+ should treat the failure of a related lease on the server side as a
+ connection failure. The default value is "true".</para>
+
+ <para><emphasis role="bold">STOP_LEASE_ON_FAILURE</emphasis> (actual value
+ "stopLeaseOnFailure") - specifies whether, when a
+ <classname>ConnectionValidator</classname> detects a connection failure, it
+ should stop the associated
+ <classname>org.jboss.remoting.LeasePinger</classname>, if any. The default
+ value is "true".</para>
+
+ </section>
</chapter>
\ No newline at end of file
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4306 - remoting2/branches/2.2/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 01:25:27 -0400 (Sun, 22 Jun 2008)
New Revision: 4306
Modified:
remoting2/branches/2.2/docs/guide/en/chap5.xml
Log:
JBREM-1001: Updated for 2.2.2.SP8.
Modified: remoting2/branches/2.2/docs/guide/en/chap5.xml
===================================================================
--- remoting2/branches/2.2/docs/guide/en/chap5.xml 2008-06-22 05:24:38 UTC (rev 4305)
+++ remoting2/branches/2.2/docs/guide/en/chap5.xml 2008-06-22 05:25:27 UTC (rev 4306)
@@ -808,13 +808,58 @@
<section>
<title>Transports (Invokers)</title>
-
+
<para>This section covers configuration issues for each of the transports,
beginning with a set of properties that apply to all transports. The
material in a later section in this chapter, <xref
linkend="section-socket-factories" />, also applies to all
transports.</para>
+
+ <section>
+ <title>Features introduced in Remoting version 2.2</title>
+ <para>Subsequent to the release of Remoting 2.2.0.GA, some transport independent features have been introduced.</para>
+
+ <section>
+ <title>Binding to 0.0.0.0</title>
+
+ <para>Before release 2.2.2.SP2, a Remoting server could bind to only one
+ specific IP address. In particular, the address 0.0.0.0 was translated
+ to the host returned by <code>java.net.InetAddress.getLocalHost()</code>
+ (or its equivalent IP address). As of release 2.2.2.SP2, a server
+ started with the address 0.0.0.0 binds to all available
+ interfaces.</para>
+
+ <para><emphasis role="bold">Note.</emphasis> If 0.0.0.0 appears in the
+ <classname>InvokerLocator</classname>, it needs to be translated to an
+ address that is usable on the client side. If the system property
+ <code>InvokerLocator.BIND_BY_HOST</code> (actual value
+ "remoting.bind_by_host") is set to "true", the
+ <classname>InvokerLocator</classname> host will be transformed to the
+ value returned by <code>InetAddress.getLocalHost().getHostName()</code>.
+ Otherwise, it will be transformed to the value returned by
+ <code>InetAddress.getLocalHost().getHostAddress()</code>. </para>
+
+ </section>
+
+ <section>
+ <title>Support for IPv6 addresses</title>
+
+ <para>As of release 2.2.2.SP4,
+ <classname>org.jboss.remoting.InvokerLocator</classname> will accept
+ IPv6 IP addresses. For example,</para>
+
+ <programlisting>
+ socket://[::1]:3333/?timeout=10000
+ socket://[::]:4444/?timeout=10000
+ socket://[::ffff:127.0.0.1]:5555/?timeout=10000
+ socket://[fe80::205:9aff:fe3c:7800%7]:6666/?timeout=10000
+ </programlisting>
+
+ </section>
+
+ </section>
+
<section>
<title>Server Invokers</title>
@@ -886,12 +931,11 @@
</section>
<section>
- <title>How the server bind address and port is ultimately
- determined</title>
+ <title>How the server bind address and port is determined</title>
<para>If the serverBindAddress property is set, the server invoker will
- bind to that address. Otherwise, it will, with two exceptions, use the
- address in the InvokerLocator (if there is one). The first exception is the
+ bind to that address. Otherwise, it will, with one exception, use the
+ address in the InvokerLocator (if there is one). The exception is the
case in which the clientConnectAddress property is set, which indicates
that the adddess in the InvokerLocator is not the real address of the
server's host. In that case, and in the case that there is no address
@@ -914,7 +958,7 @@
use local host address
</programlisting>
- <para>There is one other exception. If the InvokerLocator address is
+ <!--para>There is one other exception. If the InvokerLocator address is
0.0.0.0 and the system property called 'remoting.bind_by_host' is set to
true, then the local host name will be used, as determined by the call</para>
@@ -928,7 +972,7 @@
<programlisting>
public static final String BIND_BY_HOST = "remoting.bind_by_host";
- </programlisting>
+ </programlisting-->
<para>If the serverBindPort property is set, it will be used. If this
value is 0 or a negative number, then the next available port will be
@@ -988,7 +1032,13 @@
zero will disable idle timeout checks on pooled server threads, in the
case was previously enabled. The default value for this property is
-1.</para>
-
+
+ <para><emphasis role="bold">continueAfterTimeout</emphasis> - indicates
+ what a server thread should do after experiencing a
+ <classname>java.net.SocketTimeoutException</classname>. If set to "true",
+ or if JBossSerialization is being used, the server thread will continue to wait for an invocation; otherwise, it
+ will return itself to the thread pool.</para>
+
<bridgehead>Configurations affecting the Socket invoker
client</bridgehead>
@@ -1147,6 +1197,29 @@
data from the client. Inactive server threads are ones that have
finished processing on a particular socket connection and have been
returned to the thread pool for later reuse. </para>
+
+ <para><emphasis role="bold">Note.</emphasis> Prior to release
+ 2.2.2.SP7, if a server thread experienced a
+ <classname>java.net.SocketTimeoutException</classname>, it would return
+ itself to the thread pool and could not be reused until a new socket
+ connection was created for it to use. In principle, it would be more
+ efficient for the server thread simply to try again to read the next
+ invocation, and, in release 2.2.2.SP7, that is what it does.
+ Unfortunately, <classname>java.io.ObjectInputStream</classname> ceases
+ to function once it experiences a
+ <classname>SocketTimeoutException</classname>. The good news is that
+ <classname>org.jboss.serial.io.JBossObjectInputStream</classname>, made
+ available by the JBossSerialization project, does not suffer from that
+ problem. Therefore, as of release 2.2.2.SP8, when it experiences a
+ <classname>SocketTimeoutException</classname>, a server thread will
+ check whether it is using a
+ <classname>JBossObjectInputStream</classname> or not and act
+ accordingly. Just to allow for the possibility that an application is
+ using yet another version of <classname>ObjectInputStream</classname>,
+ the parameter <code>ServerThread.CONTINUE_AFTER_TIMEOUT</code> (actual
+ value "continueAfterTimeout") allows the behavior following a
+ <classname>SocketTimeoutException</classname> to be configured
+ explicitly.</para>
<bridgehead>client</bridgehead>
@@ -1178,6 +1251,20 @@
socket connection to be recreated. A typical scenario when this might
occur is when have had a burst of client invocations and then a long
period of inactivity.</para>
+
+ <para><emphasis role="bold">Note. </emphasis> As of release 2.2.2.GA,
+ the server side of the socket transport can capture the IP address of
+ the client side of a TCP connection from client to server and make it
+ available to application code on the client side. The address can be
+ retrieved as follows:</para>
+
+ <programlisting>
+ Client client = new Client(locator);
+ ...
+ InvocationResponse response = (InvocationResponse) client.invoke("$GET_CLIENT_LOCAL_ADDRESS$");
+ InetAddress address = (InetAddress) response.getResult();
+ </programlisting>
+
</section>
</section>
@@ -1641,6 +1728,16 @@
WebServerError and returned as this type. The raw data from the web
server can the be retrieved by getting the WebServerError's
message.</para>
+
+ <para><emphasis role="bold">Note.</emphasis> Prior to Remoting release
+ 2.2.2.SP2, the servlet transport returned a simple error message in the
+ event of an error on the server side. As of release 2.2.2.SP2, the
+ exception handling behavior described above can be requested for the the
+ servlet and sslservlet transports as well by configuring the server with
+ the parameter
+ <code>org.jboss.remoting.transport.http.HTTPMetadataConstants.RETURN_EXCEPTION</code>
+ (actual value "return-exception") set to "true".</para>
+
</section>
<section id="section-multiplex-invoker" xreflabel="Multiplex Invoker">
@@ -3425,7 +3522,7 @@
The main distinction in type of callback setup is whether the callbacks will
be push (asynchronous) or pull (synchronous) callbacks.</para>
- <section>
+ <section id="subsection-pull-callbacks" xreflabel="Pull callbacks">
<title>Pull callbacks.</title>
<para>
@@ -3469,6 +3566,40 @@
together identify a particular callback connection.
</para>
+ <para><emphasis role="bold">Note. </emphasis>As of Remoting release
+ 2.2.2.GA, there are two versions of pull callbacks: non-blocking
+ (original) and blocking (new). In the original, non-blocking mode, a
+ call to <classname>Client.getCallbacks()</classname> will return more or
+ less immediately, whether or not any callbacks are waiting on the server
+ side. In the new, blocking mode, the call will block on the server side
+ until either it times out or a callback becomes available. The blocking
+ mode eliminates the overhead of busy polling. Blocking and non-blocking
+ mode are configured on a per-invocation basis by setting
+ <code>org.jboss.remoting.ServerInvoker.BLOCKING_MODE</code> (actual
+ value "blockingMode") to either
+ <classname>ServerInvoker.BLOCKING</classname> (actual value "blocking")
+ or <classname>ServerInvoker.NONBLOCKING</classname> (actual value
+ "nonblocking") in the metadata map passed to</para>
+
+ <programlisting>
+ public List getCallbacks(InvokerCallbackHandler callbackHandler, Map metadata) throws Throwable;
+ </programlisting>
+
+ <para>in <classname>org.jboss.remoting.Client</classname>. The default
+ value is <code>ServerInvoker.NONBLOCKING</code>. The blocking timeout
+ value may be configured in two ways:</para>
+
+ <orderedlist>
+ <listitem><para>the <classname>Connector</classname> can be
+ configured with a default value; and</para>
+ </listitem>
+ <listitem><para>a per-invocation timeout value can be configured with
+ the key <code>ServerInvoker.BLOCKING_TIMEOUT</code> in the metadata
+ map passed to <methodname>Client.getCallbacks()</methodname>.</para>
+ </listitem>
+ </orderedlist>
+
+ <para>In the absence of any configured timeout, the default value is 5000 ms.</para>
</section>
<section>
@@ -3664,17 +3795,30 @@
with only one callback connection.
</para>
+ <para><emphasis role="bold">Note. </emphasis>As of Remoting release
+ 2.2.2.GA, there are two versions of pull callbacks: non-blocking
+ (original) and blocking (new). For more information, see <xref
+ linkend="subsection-pull-callbacks"/>. Since the
+ <classname>CallbackPoller</classname> uses pull callbacks, this
+ distinction is relevant to polled callbacks as well. The default
+ behavior of <classname>CallbackPoller</classname> is to use non-blocking
+ mode, but blocking mode can be requested by using the key
+ <code>ServerInvoker.BLOCKING_MODE</code> set to
+ <code>ServerInvoker.BLOCKING</code> in the metadata map passed to
+ <methodname>Client.addListener()</methodname>.</para>
+
<para>
- There are six parameters that can be passed to
+ There are nine parameters that can be passed to
<methodname>addListener()</methodname> in the <code>metadata</code>
map which are specific to push callback configuration. The first three
- apply to push callbacks and the latter three apply to polled
+ apply to push callbacks and the latter six apply to polled
callbacks. For convenience, the keys related to push callbacks are
defined as constants in the
<classname>org.jboss.remoting.Client</classname> class, and the keys
related to polled callbacks are defined in the
<classname>org.jboss.remoting.callback.CallbackPoller</classname>
- class.
+ class(with the exception of
+ <code>ServerInvoker.BLOCKING_MODE</code> and <code>ServerInvoker.BLOCKING_TIMEOUT</code>).
</para>
<para>
@@ -3727,12 +3871,52 @@
<classname>CallbackPoller</classname> to print statistics that might
be useful for configuring the other parameters..
</para>
+
+ <para>
+ <emphasis role="bold">MAX_ERROR_COUNT</emphasis> (actual value is
+ "maxErrorCount"): determines the maximum number of errors that may
+ be experienced during polling before
+ <classname>CallbackPoller</classname> will shut itself down. The
+ default value is "5".
+ </para>
+ <para>
+ <emphasis role="bold">SYNCHRONIZED_SHUTDOWN</emphasis> (actual value
+ is "doSynchronizedShutdown"): if set to "true",
+ <methodname>CallbackPoller.stop()</methodname> will wait for
+ <methodname>Client.getCallbacks()</methodname> to return, and if set
+ to "false" it will not wait. For blocking polled callbacks, the
+ default value is "false" and for non-blocking polled callbacks, the
+ default value is "true".
+ </para>
+
+ <para>
+ <emphasis role="bold">BLOCKING_MODE</emphasis> (actual value is
+ "blockingMode"): if set to <code>ServerInvoker.BLOCKING</code>
+ (actual value "blocking"), <classname>CallbackPoller</classname>
+ will do blocking polled callbacks, and if set to
+ <code>ServerInvoker.NONBLOCKING</code> (actual value "nonblocking"),
+ <classname>CallbackPoller</classname> will do non-blocking polled
+ callbacks.
+ </para>
+
<para>
Note that all of the elements in <code>metadata</code> will be passed
to the callback <classname>Connector</classname> and appended to its
<classname>InvokerLocator</classname>.
</para>
+
+ <para><emphasis role="bold">Note. </emphasis> As of Remoting release
+ 2.2.2.GA, it is possible to configure a server side timeout value for
+ sending push callbacks that is distinct from the timeout value used by
+ the server. The parameter is
+ <code>org.jboss.remoting.callback.ServerInvokerCallbackHandler.CALLBACK_TIMEOUT</code>
+ (actual value "callbackTimeout"), and it should be used to configure the
+ <classname>Connector</classname>. In the absence of
+ <code>ServerInvokerCallbackHandler.CALLBACK_TIMEOUT</code>, the timeout
+ value configured for the <classname>Connector</classname> will be
+ used.</para>
+
</section>
</section>
@@ -3940,6 +4124,23 @@
callback listener proxy on the server side. The number of exceptions the
DefaultCallbackErrorHandler will allow before removing the listener can
by configured by the 'callbackErrorsAllowed' attribute.</para>
+
+ <para><emphasis role="bold">Note. </emphasis>As of Remoting release
+ 2.2.2.SP4, an
+ <classname>org.jboss.remoting.callback.ServerInvokerCallbackHandler</classname>,
+ which manages both push and pull callbacks on the server side, can
+ register to be informed of a failure on the connection to the client that
+ it is servicing. In particular, if there is a lease registered for the
+ connection for that particular client, then the
+ <classname>ServerInvokerCallbackHandler</classname> can be registered as a
+ <classname>org.jboss.remoting.ConnectionListener</classname> for that
+ lease. The default behavior is to do the registration, but the parameter
+ <code>org.jboss.remoting.ServerInvoker.REGISTER_CALLBACK_LISTENER</code>
+ (actual value "registerCallbackListener") may be set to "false" to prevent
+ registration. If leasing is enabled and registration is turned on, a
+ <classname>ServerInvokerCallbackHandler</classname> will shut itself down
+ upon being informed of a connection failure. For more information about
+ leasing, see <xref linkend="chapter-connection-failure"/>.</para>
</section>
</section>
@@ -5957,6 +6158,33 @@
instance of it (which requires it to have a void constructor). The
instance will then be cast to type javax.net.ServerSocketFactory.</para>
+ <para>
+ <emphasis role="bold">BLOCKING_MODE</emphasis> (actual value is
+ "blockingMode"): if set to <code>ServerInvoker.BLOCKING</code> (actual
+ value "blocking"),
+ <methodname>org.jboss.remoting.Client.getCallbacks()</methodname> will do
+ blocking pull callbacks and <classname>CallbackPoller</classname> will do
+ blocking polled callbacks; if set to
+ <code>ServerInvoker.NONBLOCKING</code> (actual value "nonblocking"),
+ <methodname>Client.getCallbacks()</methodname> will do non-blocking pull
+ callbacks and <classname>CallbackPoller</classname> will do non-blocking
+ polled callbacks.
+ </para>
+
+ <para>
+ <emphasis role="bold">BLOCKING_TIMEOUT</emphasis> (actual value is
+ "blockingTimeout"): the timeout value used for blocking callback.
+ </para>
+
+ <para>
+ <emphasis role="bold">REGISTER_CALLBACK_LISTENER</emphasis> (actual value
+ is "registerCallbackListener"): determines if
+ <classname>org.jboss.remoting.callback.ServerInvokerCallbackHandler</classname>s
+ should register as
+ <classname>org.jboss.remoting.ConnectionListener</classname>s with leases.
+ The default value is "true".
+ </para>
+
<para></para>
<para><emphasis role="bold">Bean properties (meaning have
@@ -6082,6 +6310,63 @@
under which detection messages will be bound and looked up.</para>
<para></para>
+
+ <bridgehead>org.jboss.remoting.transport.bisocket.Bisocket</bridgehead>
+ <para>
+ <emphasis role="bold">IS_CALLBACK_SERVER</emphasis> (actual value is
+ "isCallbackServer"): when a bisocket server invoker receives this
+ parameter with a value of true, it avoids the creation of a
+ <classname>ServerSocket</classname>. Therefore, IS_CALLBACK_SERVER
+ should be used on the client side for the creation of a callback
+ server. The default value is false.
+ </para>
+
+ <para>
+ <emphasis role="bold">PING_FREQUENCY</emphasis> (actual
+ value is "pingFrequency"): The server side uses this value
+ to determine the interval, in milliseconds, between pings that it will
+ send on the control connection. The client side uses this value to
+ calculate the window in which it must receive pings on the control
+ connection. In particular, the window is ping frequency * ping window factor.
+ See also the definition of PING_WINDOW_FACTOR. The default value is 5000.
+ </para>
+
+ <para>
+ <emphasis role="bold">PING_WINDOW_FACTOR</emphasis> (actual
+ value is "pingWindowFactor"): The client side uses this value to
+ calculate the window in which it must receive pings on the control
+ connection. In particular, the window is ping frequency * ping window factor.
+ See also the definition of PING_FREQUENCY. The default value is 2.
+ </para>
+
+ <para>
+ <emphasis role="bold">MAX_RETRIES </emphasis> (actual value is
+ "maxRetries"): This parameter is relevant only on the client side,
+ where the <classname>BisocketClientInvoker</classname> uses it
+ to govern the number of attempts it should make to get the address and
+ port of the secondary <classname>ServerSocket</classname>, and the
+ <classname>BisocketServerInvoker</classname> uses it to govern the
+ number of attempts it should make to create both ordinary and control
+ sockets. The default value is 10. </para>
+
+ <para>
+ <emphasis role="bold">MAX_CONTROL_CONNECTION_RESTARTS</emphasis>
+ (actual value is "maxControlConnectionRestarts"): The client side uses
+ this value to limit the number of times it will request a new control
+ connection after a ping timeout. The default value is 10.
+ </para>
+
+ <para>
+ <emphasis role="bold">SECONDARY_BIND_PORT</emphasis> (actual value is
+ "secondaryBindPort"): The server side uses this parameter to determine
+ the bind port for the secondary
+ <classname>ServerSocket</classname>.</para>
+
+ <para>
+ <emphasis role="bold">SECONDARY_CONNECT_PORT</emphasis> (actual value
+ is "secondaryConnectPort"): The server side uses this parameter to
+ determine the connect port used by the client side to connect to the
+ secondary <classname>ServerSocket</classname>.</para>
<bridgehead>org.jboss.remoting.transport.http.HTTPMetadataConstants</bridgehead>
@@ -6186,6 +6471,12 @@
originated on the server (if using remoting server) or throw a
org.jboss.remoting.transport.http.WebServerError, whose message will be
the error html returned from the web server.</para>
+
+ <para><emphasis role="bold">RETURN_EXCEPTION</emphasis> (actual value is
+ 'return-exception') - key indicating if
+ <classname>org.jboss.remoting.transport.servlet.ServletServerInvoker</classname>
+ should throw an exception instead of the orginal error handling behavior of
+ returning an error message.</para>
<para></para>
@@ -6250,6 +6541,15 @@
<para></para>
+ <bridgehead>org.jboss.remoting.transport.socket.ServerThread</bridgehead>
+
+ <para><emphasis role="bold">CONTINUE_AFTER_TIMEOUT</emphasis> (actual value
+ "continueAfterTimeout") - indicates what a server thread should do after
+ experiencing a <classname>java.net.SocketTimeoutException</classname>. If
+ set to "true", or if JBossSerialization is being used, the server thread
+ will continue to wait for an invocation; otherwise, it will return itself to
+ the thread pool.</para>
+
<bridgehead>org.jboss.remoting.transport.socket.SocketServerInvoker</bridgehead>
<para><emphasis role="bold">CHECK_CONNECTION_KEY</emphasis> (actual value
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4305 - remoting2/branches/2.2/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 01:24:38 -0400 (Sun, 22 Jun 2008)
New Revision: 4305
Modified:
remoting2/branches/2.2/docs/guide/en/chap16.xml
Log:
JBREM-1001: Updated for 2.2.2.SP8.
Modified: remoting2/branches/2.2/docs/guide/en/chap16.xml
===================================================================
--- remoting2/branches/2.2/docs/guide/en/chap16.xml 2008-06-22 05:22:46 UTC (rev 4304)
+++ remoting2/branches/2.2/docs/guide/en/chap16.xml 2008-06-22 05:24:38 UTC (rev 4305)
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter>
- <title>Release Notes</title>
+ <title id="chapter-release-notes" xreflabel="Release Notes">Release Notes</title>
<bridgehead>Important changes and differences in 2.2.0 release (from 2.0.0
release)</bridgehead>
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4304 - remoting2/branches/2.2/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-22 01:22:46 -0400 (Sun, 22 Jun 2008)
New Revision: 4304
Modified:
remoting2/branches/2.2/docs/guide/en/chap1.xml
Log:
JBREM-1001: Updated for 2.2.2.SP8.
Modified: remoting2/branches/2.2/docs/guide/en/chap1.xml
===================================================================
--- remoting2/branches/2.2/docs/guide/en/chap1.xml 2008-06-20 04:58:44 UTC (rev 4303)
+++ remoting2/branches/2.2/docs/guide/en/chap1.xml 2008-06-22 05:22:46 UTC (rev 4304)
@@ -177,4 +177,87 @@
distribution includes binaries, source, documentation, javadoc, and sample
code.</para>
</section>
+
+ <section>
+ <title>What's new?</title>
+
+ <section>
+ <title>In release 2.2.2.SP7</title>
+
+ <orderedlist>
+ <listitem><para>Server side and client side connection listeners can be
+ tied together.</para>
+ </listitem>
+ </orderedlist>
+
+ </section>
+
+ <section>
+ <title>In release 2.2.2.SP4</title>
+
+ <orderedlist>
+ <listitem><para>IPv6 addresses are supported;</para></listitem>
+
+ <listitem><para><classname>org.jboss.remoting.callback.ServerInvokerCallbackHandler</classname>
+ can register itself as a lease connection listener.</para>
+ </listitem>
+ </orderedlist>
+
+ </section>
+
+ <section>
+ <title>In release 2.2.2.SP2</title>
+
+ <orderedlist>
+ <listitem><para>The servlet transport can throw an exception generated on
+ the server side;</para></listitem>
+
+ <listitem><para>servers can bind to 0.0.0.0.</para>
+ </listitem>
+ </orderedlist>
+
+ </section>
+
+ <section>
+ <title>In release 2.2.2.GA</title>
+
+ <para>Release 2.2.2.GA includes a number of bug fixes, greater
+ configurability, and a couple of new features, including</para>
+
+ <orderedlist>
+ <listitem><para>an improved callback polling method;</para></listitem>
+
+ <listitem><para>the ability for the client to discover its IP address as
+ seen by the server side of the connection;</para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>The following changes affect configurability:</para>
+
+ <orderedlist>
+ <listitem>
+ <para>The address and port of the bisocket transport secondary server
+ socket are configurable;</para>
+ </listitem>
+
+ <listitem>
+ <para><classname>org.jboss.remoting.ConnectorValidator</classname> parameters are configurable;</para>
+ </listitem>
+
+ <listitem>
+ <para>the maximum number of errors before a <classname>org.jboss.remoting.callback.CallbackPoller</classname> shuts down can be specified;</para>
+ </listitem>
+
+ <listitem>
+ <para>there is a separate timeout parameter for callbacks.</para>
+ </listitem>
+ </orderedlist>
+
+
+ <para>For the JIRA items related to release 2.2.2.GA, see <xref
+ linkend="chapter-release-notes"/>.</para>
+
+ </section>
+ </section>
</chapter>
\ No newline at end of file
16 years, 5 months
- 1
- 0