jboss-remoting-commits
June 2008
jboss-remoting-commits@lists.jboss.org
- 1 participants
- 64 discussions
JBoss Remoting SVN: r4283 - 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-10 01:47:14 -0400 (Tue, 10 Jun 2008)
New Revision: 4283
Modified:
remoting2/branches/2.2/src/main/org/jboss/remoting/ServerInvoker.java
Log:
JBREM-981: Moved validateLocator() from ServerInvoker to InvokerLocator.
Modified: remoting2/branches/2.2/src/main/org/jboss/remoting/ServerInvoker.java
===================================================================
--- remoting2/branches/2.2/src/main/org/jboss/remoting/ServerInvoker.java 2008-06-10 05:46:06 UTC (rev 4282)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/ServerInvoker.java 2008-06-10 05:47:14 UTC (rev 4283)
@@ -1127,69 +1127,15 @@
}
createServerSocketFactory();
-
+
// need to check invoker locator to see if need to provide binding address (in the case 0.0.0.0 was used)
- locator = validateLocator(locator);
+ InvokerLocator originalLocator = locator;
+ locator = InvokerLocator.validateLocator(locator);
+
+ // need to update the locator key used in the invoker registry
+ InvokerRegistry.updateServerInvokerLocator(originalLocator, locator);
}
- /**
- * InvokerLocator leaves address 0.0.0.0 unchanged. Once serverBindAddress has been
- * extracted from the InvokerLocator, it is necessary to transform 0.0.0.0 into an
- * address that contacted over the network. See JBREM-687.
- */
- private InvokerLocator validateLocator(InvokerLocator locator) throws MalformedURLException
- {
- InvokerLocator externalLocator = locator;
-
- String host = locator.getHost();
- String newHost = null;
- if(host == null || InvokerLocator.ANY.equals(host))
- {
- // now need to get some external bindable address
- boolean byHost = true;
- String bindByHost = System.getProperty(InvokerLocator.BIND_BY_HOST, "True");
- try
- {
- byHost = Boolean.valueOf(bindByHost).booleanValue();
- }
- catch(Exception e)
- {
- }
- try
- {
- if(byHost)
- {
- newHost = InetAddress.getLocalHost().getHostName();
- }
- else
- {
- newHost = InetAddress.getLocalHost().getHostAddress();
- }
- }
- catch (UnknownHostException e)
- {
- log.debug("Could not get host by name or address.", e);
- }
- if(newHost == null)
- {
- // now what? step through network interfaces?
- throw new RuntimeException("Can not determine bindable address for locator (" + locator + ")");
- }
-
- // now create new locator with new host
- externalLocator = new InvokerLocator(locator.protocol,
- newHost,
- locator.getPort(),
- locator.getPath(),
- locator.getParameters());
-
- // need to update the locator key used in the invoker registry
- InvokerRegistry.updateServerInvokerLocator(locator, externalLocator);
- }
-
- return externalLocator;
- }
-
protected int assignPort() throws IOException
{
int port;
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4282 - 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-10 01:46:06 -0400 (Tue, 10 Jun 2008)
New Revision: 4282
Modified:
remoting2/branches/2.2/src/main/org/jboss/remoting/InvokerLocator.java
Log:
JBREM-981: Moved validateLocator() from ServerInvoker to InvokerLocator.
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-10 02:16:37 UTC (rev 4281)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/InvokerLocator.java 2008-06-10 05:46:06 UTC (rev 4282)
@@ -32,6 +32,9 @@
import java.net.URI;
import java.net.URISyntaxException;
import java.net.UnknownHostException;
+import java.security.AccessController;
+import java.security.PrivilegedActionException;
+import java.security.PrivilegedExceptionAction;
import java.util.Iterator;
import java.util.Map;
import java.util.StringTokenizer;
@@ -102,7 +105,58 @@
{
legacyParsingFlag = new Boolean(flag);
}
+
+ /**
+ * InvokerLocator leaves address 0.0.0.0 unchanged. Once serverBindAddress has been
+ * extracted from the InvokerLocator, it is necessary to transform 0.0.0.0 into an
+ * address that contacted over the network. See JBREM-687.
+ */
+ public static InvokerLocator validateLocator(InvokerLocator locator) throws MalformedURLException
+ {
+ InvokerLocator externalLocator = locator;
+ String host = locator.getHost();
+ String newHost = null;
+ if(host == null || InvokerLocator.ANY.equals(host))
+ {
+ // now need to get some external bindable address
+ try
+ {
+ newHost = (String)AccessController.doPrivileged( new PrivilegedExceptionAction()
+ {
+ public Object run() throws Exception
+ {
+ String bindByHost = System.getProperty(InvokerLocator.BIND_BY_HOST, "True");
+ boolean byHost = Boolean.valueOf(bindByHost).booleanValue();
+ if(byHost)
+ {
+ return InetAddress.getLocalHost().getHostName();
+ }
+ else
+ {
+ return InetAddress.getLocalHost().getHostAddress();
+ }
+ }
+ });
+ }
+ catch (PrivilegedActionException e)
+ {
+ log.debug("Could not get host by name or address.", e.getCause());
+ }
+
+ if(newHost == null)
+ {
+ // now what? step through network interfaces?
+ throw new RuntimeException("Can not determine bindable address for locator (" + locator + ")");
+ }
+
+ externalLocator = new InvokerLocator(locator.protocol, newHost, locator.port,
+ locator.getPath(), locator.getParameters());
+ }
+
+ return externalLocator;
+ }
+
/**
* Indicates should address binding to all network interfaces (i.e. 0.0.0.0)
*/
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4281 - remoting2/branches/2.2/src/main/org/jboss/remoting/transport.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-09 22:16:37 -0400 (Mon, 09 Jun 2008)
New Revision: 4281
Modified:
remoting2/branches/2.2/src/main/org/jboss/remoting/transport/PortUtil.java
Log:
JBREM-965: Replace getRandomStartingPort() with simple call to SecureRandom.nextInt().
Modified: remoting2/branches/2.2/src/main/org/jboss/remoting/transport/PortUtil.java
===================================================================
--- remoting2/branches/2.2/src/main/org/jboss/remoting/transport/PortUtil.java 2008-06-10 02:11:16 UTC (rev 4280)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/transport/PortUtil.java 2008-06-10 02:16:37 UTC (rev 4281)
@@ -26,6 +26,8 @@
import java.net.InetAddress;
import java.io.IOException;
import java.security.SecureRandom;
+import java.util.Random;
+
import org.jboss.logging.Logger;
/**
@@ -140,13 +142,10 @@
}
public static int getRandomStartingPort()
- {
- Object o = new Object();
- String os = o.toString();
- os = os.substring(17);
- int n = Integer.parseInt(os, 16);
- int p = Math.abs(new SecureRandom(String.valueOf(System.currentTimeMillis() + n).getBytes()).nextInt(2000)) + 2000;
- return p;
+ {
+ int range = MAX_LEGAL_PORT - MIN_UNPRIVILEGED_PORT + 1;
+ int port = new Random(System.currentTimeMillis()).nextInt(range) + MIN_UNPRIVILEGED_PORT;
+ return port;
}
public static void main(String args[])
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4280 - in remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket: interrupt and 1 other directory.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-09 22:11:16 -0400 (Mon, 09 Jun 2008)
New Revision: 4280
Added:
remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/
remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/InterruptedExceptionTestCase.java
remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/MockInvokerInterruptTestCase.java
Log:
JBREM-954: New unit tests.
Added: remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/InterruptedExceptionTestCase.java
===================================================================
--- remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/InterruptedExceptionTestCase.java (rev 0)
+++ remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/InterruptedExceptionTestCase.java 2008-06-10 02:11:16 UTC (rev 4280)
@@ -0,0 +1,240 @@
+/*
+* 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.interrupt;
+
+import java.net.InetAddress;
+import java.util.HashMap;
+import java.util.Map;
+
+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.CannotConnectException;
+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.InvokerCallbackHandler;
+import org.jboss.remoting.transport.Connector;
+import org.jboss.remoting.transport.PortUtil;
+import org.jboss.remoting.transport.socket.MicroSocketClientInvoker;
+
+
+/**
+ * Unit test for JBREM-955.
+ *
+ * @author <a href="ron.sigal(a)jboss.com">Ron Sigal</a>
+ * @version $Revision: 1.1 $
+ * <p>
+ * Copyright Apr 25, 2008
+ * </p>
+ */
+public class InterruptedExceptionTestCase extends TestCase
+{
+ private static Logger log = Logger.getLogger(InterruptedExceptionTestCase.class);
+
+ private static boolean firstTime = true;
+ private static String FAST = "fast";
+
+ 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 testInterruptedException() throws Throwable
+ {
+ log.info("entering " + getName());
+
+ // Start server.
+ setupServer();
+
+ // Create client.
+ InvokerLocator clientLocator = new InvokerLocator(locatorURI);
+ HashMap clientConfig = new HashMap();
+ clientConfig.put(InvokerLocator.FORCE_REMOTE, "true");
+ clientConfig.put(MicroSocketClientInvoker.MAX_POOL_SIZE_FLAG, "1");
+ clientConfig.put("numberOfCallRetries", "1");
+ addExtraClientConfig(clientConfig);
+ Client client = new Client(clientLocator, clientConfig);
+ client.connect();
+ log.info("client is connected");
+
+ // Test connections.
+ assertEquals(FAST, client.invoke(FAST));
+ log.info("connection is good");
+
+ InvokerThread t1 = new InvokerThread(client, "abc");
+ InvokerThread t2 = new InvokerThread(client, "xyz");
+
+ // Start first invocation.
+ t1.start();
+ log.info("started first invocation");
+
+ // Give first invocation time to start.
+ Thread.sleep(5000);
+
+ // Start second invocation.
+ t2.start();
+ log.info("started second invocation");
+
+ // Give second invocation time to start.
+ Thread.sleep(5000);
+
+ // Interrupt second invocation as it waits for a semaphore.
+ t2.interrupt();
+ log.info("interrupted second invocation");
+
+ // Wait until second invocation throws an exception.
+ synchronized (t2)
+ {
+ t2.wait(10000);
+ }
+
+ // Verify exception is an InterruptedException wrapped in a RuntimeExceptio.
+ Throwable t = t2.throwable;
+ log.info("throwable: " + t);
+ assertTrue(t instanceof RuntimeException);
+ assertFalse(t instanceof CannotConnectException);
+ assertTrue(t.getCause() instanceof InterruptedException);
+
+ 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() throws Exception
+ {
+ host = InetAddress.getLocalHost().getHostAddress();
+ port = PortUtil.findFreePort(host);
+ locatorURI = getTransport() + "://" + host + ":" + port;
+ 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
+ {
+ Object o = invocation.getParameter();
+ if (!FAST.equals(o))
+ {
+ Thread.sleep(20000);
+ }
+ return invocation.getParameter();
+ }
+ public void removeListener(InvokerCallbackHandler callbackHandler) {}
+ public void setMBeanServer(MBeanServer server) {}
+ public void setInvoker(ServerInvoker invoker) {}
+ }
+
+
+ static class InvokerThread extends Thread
+ {
+ static int counter;
+ Client client;
+ String message;
+ Throwable throwable;
+
+ public InvokerThread(Client client, String message)
+ {
+ this.client = client;
+ this.message = message;
+ setName("InvokerThread:" + counter++);
+ }
+
+ public void run()
+ {
+ try
+ {
+ log.info("invocation succeeded: " + client.invoke(message));
+ }
+ catch (Throwable t)
+ {
+ throwable = t;
+ log.error("invocation error: " + t.getMessage());
+ }
+
+ synchronized (this)
+ {
+ notify();
+ }
+ }
+ }
+}
\ No newline at end of file
Added: remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/MockInvokerInterruptTestCase.java
===================================================================
--- remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/MockInvokerInterruptTestCase.java (rev 0)
+++ remoting2/branches/2.2/src/tests/org/jboss/test/remoting/transport/socket/interrupt/MockInvokerInterruptTestCase.java 2008-06-10 02:11:16 UTC (rev 4280)
@@ -0,0 +1,131 @@
+/*
+ * JBoss, Home of Professional Open Source.
+ * Copyright 2008, Red Hat Middleware LLC, and individual contributors
+ * as indicated by the @author tags. See the copyright.txt file 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.interrupt;
+
+import junit.framework.TestCase;
+
+import org.apache.log4j.Logger;
+import org.jboss.remoting.CannotConnectException;
+import org.jboss.remoting.InvocationRequest;
+import org.jboss.remoting.InvokerLocator;
+import org.jboss.remoting.marshal.Marshaller;
+import org.jboss.remoting.marshal.UnMarshaller;
+import org.jboss.remoting.transport.socket.MicroSocketClientInvoker;
+import org.jboss.remoting.transport.socket.SocketWrapper;
+
+import EDU.oswego.cs.dl.util.concurrent.CountDown;
+
+/**
+ * Unit test for JBREM-955.
+ *
+ * @author <a href="mailto:galder.zamarreno@jboss.com">Galder Zamarreno</a>
+ */
+public class MockInvokerInterruptTestCase extends TestCase
+{
+ private static final Logger log = Logger.getLogger(MockInvokerInterruptTestCase.class);
+
+ public void test000() throws Throwable
+ {
+ InvokerLocator il = new InvokerLocator("unittest", "127.0.0.1", 9999, "mock", null);
+ CountDown startGate = new CountDown(1);
+ MockMicroSocketClientInvoker ci = new MockMicroSocketClientInvoker(il, startGate);
+ InvocationRequest ir = new InvocationRequest("", "", null, null, null, il);
+
+ Runnable interrupterRunnable = new ThreadInterrupter(Thread.currentThread(), startGate);
+ Thread interrupter = new Thread(interrupterRunnable);
+ interrupter.start();
+
+ ci.setMaxPoolSize(0);
+ ci.connect();
+ try
+ {
+ ci.invoke(ir);
+ }
+ catch(CannotConnectException cce)
+ {
+ log.error("We interrupted the connection, a more meaningul exception should be thrown");
+ throw cce;
+ }
+ catch (RuntimeException re)
+ {
+ assertTrue(re.getCause() instanceof InterruptedException);
+ }
+ }
+
+ class MockMicroSocketClientInvoker extends MicroSocketClientInvoker
+ {
+ private CountDown startGate;
+
+ public MockMicroSocketClientInvoker(InvokerLocator locator, CountDown start)
+ {
+ super(locator);
+ startGate = start;
+ }
+
+ public void setMaxPoolSize(int maxPoolSize)
+ {
+ this.maxPoolSize = maxPoolSize;
+ }
+
+ protected SocketWrapper getConnection(Marshaller marshaller, UnMarshaller unmarshaller,
+ int timeAllowed)
+ throws Exception
+ {
+ log.info("Request a connection but before that, let's open the start gate");
+ startGate.release();
+ return super.getConnection(marshaller, unmarshaller, timeAllowed);
+ }
+ }
+
+ class ThreadInterrupter implements Runnable
+ {
+ private Thread threadToInterrupt;
+
+ private CountDown startGate;
+
+ ThreadInterrupter(Thread thread, CountDown start)
+ {
+ threadToInterrupt = thread;
+ startGate = start;
+ }
+
+ public void run()
+ {
+ try
+ {
+ log.info("Wait for start gate to be opened");
+ startGate.acquire();
+
+ log.info("Start gate opened, let's sleep briefly...");
+ Thread.sleep(200);
+
+ log.info("Sleep finished, interrupt the target thread");
+ threadToInterrupt.interrupt();
+ }
+ catch (InterruptedException e)
+ {
+ log.error("Error", e);
+ }
+ }
+
+ }
+}
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4279 - remoting2/branches/2.2/src/tests/org/jboss/test/remoting/connection.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-09 22:03:51 -0400 (Mon, 09 Jun 2008)
New Revision: 4279
Modified:
remoting2/branches/2.2/src/tests/org/jboss/test/remoting/connection/ConnectionValidatorConfigTestClient.java
Log:
JBREM-860: Eliminated tests involving "numberOfRetries" parameter.
Modified: remoting2/branches/2.2/src/tests/org/jboss/test/remoting/connection/ConnectionValidatorConfigTestClient.java
===================================================================
--- remoting2/branches/2.2/src/tests/org/jboss/test/remoting/connection/ConnectionValidatorConfigTestClient.java 2008-06-10 01:58:04 UTC (rev 4278)
+++ remoting2/branches/2.2/src/tests/org/jboss/test/remoting/connection/ConnectionValidatorConfigTestClient.java 2008-06-10 02:03:51 UTC (rev 4279)
@@ -123,10 +123,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -178,10 +174,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -235,10 +227,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -292,10 +280,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -350,10 +334,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -407,10 +387,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -464,10 +440,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -521,10 +493,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -579,10 +547,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -635,10 +599,6 @@
assertTrue(invoker instanceof MicroSocketClientInvoker);
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
assertEquals(13, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -691,10 +651,6 @@
assertTrue(invoker instanceof MicroSocketClientInvoker);
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
assertEquals(7, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -748,10 +704,6 @@
assertTrue(invoker instanceof MicroSocketClientInvoker);
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
assertEquals(19, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -805,9 +757,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- assertEquals(21, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -861,9 +810,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- assertEquals(27, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -918,9 +864,6 @@
MicroSocketClientInvoker socketInvoker = (MicroSocketClientInvoker) invoker;
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
-
- // Test connection retries.
- assertEquals(33, socketInvoker.getNumberOfRetries());
client.disconnect();
}
@@ -974,10 +917,6 @@
int defaultPingRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_PING_RETRIES);
assertEquals(defaultPingRetries, socketInvoker.getNumberOfCallRetries());
- // Test connection retries.
- int defaultConnectionRetries = Integer.parseInt(ConnectionValidator.DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
- assertEquals(defaultConnectionRetries, socketInvoker.getNumberOfRetries());
-
// Test ReuseAddress.
assertFalse(socketInvoker.getReuseAddress());
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4278 - 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-09 21:58:04 -0400 (Mon, 09 Jun 2008)
New Revision: 4278
Modified:
remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/MicroSocketClientInvoker.java
remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/SocketClientInvoker.java
Log:
JBREM-954: Wraps InterruptedException in a RuntimeException.
Modified: remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/MicroSocketClientInvoker.java
===================================================================
--- remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/MicroSocketClientInvoker.java 2008-06-10 01:43:37 UTC (rev 4277)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/MicroSocketClientInvoker.java 2008-06-10 01:58:04 UTC (rev 4278)
@@ -550,6 +550,12 @@
{
socketWrapper = getConnection(marshaller, unmarshaller, timeLeft);
}
+ catch (InterruptedException e)
+ {
+ semaphore.release();
+ if (trace) log.trace(this + " released semaphore: " + semaphore.permits(), e);
+ throw new RuntimeException(e);
+ }
catch (Exception e)
{
// if (bailOut)
@@ -718,6 +724,12 @@
throw (ClassNotFoundException)ex;
}
+ if (ex instanceof InterruptedException)
+ {
+ log.debug(this, ex);
+ throw new RuntimeException(ex);
+ }
+
throw new MarshalException(
"Failed to communicate. Problem during marshalling/unmarshalling.", ex);
}
Modified: remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/SocketClientInvoker.java
===================================================================
--- remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/SocketClientInvoker.java 2008-06-10 01:43:37 UTC (rev 4277)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/transport/socket/SocketClientInvoker.java 2008-06-10 01:58:04 UTC (rev 4278)
@@ -118,7 +118,12 @@
throw new MarshalException("Socket timed out. Waited " + socketWrapper.getTimeout() + " milliseconds for response while calling on " +
getLocator(), ex);
}
-
+ else if (ex instanceof InterruptedException)
+ {
+ log.debug(this, ex);
+ throw new RuntimeException(ex);
+ }
+
throw new MarshalException("Failed to communicate. Problem during marshalling/unmarshalling", ex);
}
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4277 - 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-09 21:43:37 -0400 (Mon, 09 Jun 2008)
New Revision: 4277
Modified:
remoting2/branches/2.2/src/main/org/jboss/remoting/ConnectionValidator.java
Log:
JBREM-949: Added a Timer so checking for invocation response is made on a separate thread; JBREM-860: eliminated "numberOfRetries" variable, which is no longer used in socket transport.
Modified: remoting2/branches/2.2/src/main/org/jboss/remoting/ConnectionValidator.java
===================================================================
--- remoting2/branches/2.2/src/main/org/jboss/remoting/ConnectionValidator.java 2008-06-08 23:43:55 UTC (rev 4276)
+++ remoting2/branches/2.2/src/main/org/jboss/remoting/ConnectionValidator.java 2008-06-10 01:43:37 UTC (rev 4277)
@@ -32,6 +32,7 @@
import java.util.List;
import java.util.ListIterator;
import java.util.Map;
+import java.util.Timer;
import java.util.TimerTask;
/**
@@ -61,12 +62,6 @@
* Currently implemented only on socket transport family.
*/
public static final String DEFAULT_NUMBER_OF_PING_RETRIES = "1";
-
- /**
- * Default number of connection acquisition retries. Value is 1.
- * Currently implemented only on socket transport family.
- */
- public static final String DEFAULT_NUMBER_OF_CONNECTION_RETRIES = "1";
/**
* Key to determine if ConnectionValidator should tie failure to presence
@@ -95,6 +90,7 @@
{
boolean pingWorked = false;
Map configMap = createPingConfig(config, null);
+ int pingTimeout = Integer.parseInt((String) configMap.get(ServerInvoker.TIMEOUT));
ClientInvoker innerClientInvoker = null;
try
@@ -107,7 +103,7 @@
innerClientInvoker.connect();
}
- pingWorked = doCheckConnection(innerClientInvoker);
+ pingWorked = doCheckConnection(innerClientInvoker, pingTimeout);
}
catch (Throwable throwable)
{
@@ -127,7 +123,7 @@
return pingWorked;
}
- private static boolean doCheckConnection(ClientInvoker clientInvoker) throws Throwable
+ private static boolean doCheckConnection(ClientInvoker clientInvoker, int pingTimeout) throws Throwable
{
boolean pingWorked = false;
@@ -136,16 +132,12 @@
// Sending null client id as don't want to trigger lease on server side. This also means
// that client connection validator will NOT impact client lease, so can not depend on it
// to maintain client lease with the server.
- InvocationRequest ir =
- new InvocationRequest(null, Subsystem.SELF, "$PING$", null, null, null);
-
- if (trace) { log.trace("pinging, sending " + ir + " over " + clientInvoker); }
-
- clientInvoker.invoke(ir);
-
- if (trace) { log.trace("ConnectionValidator got successful ping using " + clientInvoker);}
-
- pingWorked = true;
+ InvocationRequest ir;
+ ir = new InvocationRequest(null, Subsystem.SELF, "$PING$", null, null, null);
+ ConnectionCheckThread t = new ConnectionCheckThread(clientInvoker, ir);
+ t.start();
+ Thread.sleep(pingTimeout);
+ pingWorked = t.isValid();
}
catch (Throwable t)
{
@@ -165,7 +157,18 @@
Object o = config.get(VALIDATOR_PING_TIMEOUT);
log.trace("config timeout: " + o);
if (o != null)
- localConfig.put(ServerInvoker.TIMEOUT, o);
+ {
+ try
+ {
+ Integer.parseInt((String) o);
+ localConfig.put(ServerInvoker.TIMEOUT, o);
+ }
+ catch (NumberFormatException e)
+ {
+ log.warn("Need integer for value of parameter " + VALIDATOR_PING_TIMEOUT +
+ ". Using default value " + DEFAULT_PING_TIMEOUT);
+ }
+ }
o = config.get("NumberOfCallRetries");
if (o != null)
@@ -182,7 +185,18 @@
localConfig.putAll(metadata);
Object o = metadata.get(VALIDATOR_PING_TIMEOUT);
if (o != null)
- localConfig.put(ServerInvoker.TIMEOUT, o);
+ {
+ try
+ {
+ Integer.parseInt((String) o);
+ localConfig.put(ServerInvoker.TIMEOUT, o);
+ }
+ catch (NumberFormatException e)
+ {
+ log.warn("Need integer for value of parameter " + VALIDATOR_PING_TIMEOUT +
+ ". Using default value " + DEFAULT_PING_TIMEOUT);
+ }
+ }
}
if (localConfig.get(ServerInvoker.TIMEOUT) == null)
@@ -191,9 +205,6 @@
if (localConfig.get("NumberOfCallRetries") == null)
localConfig.put("NumberOfCallRetries", DEFAULT_NUMBER_OF_PING_RETRIES);
- if (localConfig.get("NumberOfRetries") == null)
- localConfig.put("NumberOfRetries", DEFAULT_NUMBER_OF_CONNECTION_RETRIES);
-
return localConfig;
}
@@ -207,10 +218,14 @@
private List listeners;
private ClientInvoker clientInvoker;
private Object lock = new Object();
+ private Object notificationLock = new Object();
private volatile boolean stopped;
private String invokerSessionId;
private boolean tieToLease = true;
private boolean stopLeaseOnFailure = true;
+ private int pingTimeout;
+ private boolean isValid;
+ private Timer timer;
// Constructors ---------------------------------------------------------------------------------
@@ -259,15 +274,26 @@
*/
public void run()
{
- synchronized(lock)
+ TimerTask tt = new WaitOnConnectionCheckTimerTask();
+
+ try
{
- if(!stopped)
+ timer.schedule(tt, 0);
+ }
+ catch (IllegalStateException e)
+ {
+ log.debug("Unable to schedule TimerTask on existing Timer", e);
+ timer = new Timer(true);
+ timer.schedule(tt, 0);
+ }
+
+ try
+ {
+ synchronized(lock)
{
- try
+ if(!stopped)
{
- if (trace) { log.trace(this + " pinging ..."); }
-
- boolean isValid = false;
+ isValid = false;
if (tieToLease && client.getLeasePeriod() > 0)
{
@@ -276,37 +302,29 @@
}
else
{
- isValid = doCheckConnection(clientInvoker);
+ if (trace) { log.trace(this + " pinging ..."); }
+ isValid = doCheckConnectionWithoutLease();
}
-
- if (!isValid)
- {
- log.debug(this + "'s connections is invalid");
-
- notifyListeners(new Exception("Could not connect to server!"));
-
- if (stopLeaseOnFailure)
- {
- log.debug(this + " detected connection failure: stopping LeasePinger");
- MicroRemoteClientInvoker invoker = (MicroRemoteClientInvoker) client.getInvoker();
- invoker.terminateLease(null, client.getDisconnectTimeout());
- log.debug(this + " shut down lease pinger");
- }
- }
}
- catch (Throwable thr)
- {
- log.debug(this + " got throwable while pinging", thr);
- notifyListeners(thr);
-
- if (stopLeaseOnFailure)
- {
- log.debug(this + " detected connection failure: stopping");
- cancel();
- }
- }
}
}
+ catch (Throwable thr)
+ {
+ log.debug(this + " got throwable while pinging", thr);
+
+ if (stopLeaseOnFailure)
+ {
+ log.debug(this + " detected connection failure: stopping");
+ cancel();
+ }
+ }
+ finally
+ {
+ synchronized (notificationLock)
+ {
+ notificationLock.notifyAll();
+ }
+ }
}
public boolean cancel()
@@ -460,7 +478,8 @@
private void start()
{
configMap = createPingConfig(client.getConfiguration(), metadata);
- log.debug(this + " timeout: " + configMap.get(ServerInvoker.TIMEOUT));
+ pingTimeout = Integer.parseInt((String) configMap.get(ServerInvoker.TIMEOUT));
+ log.debug(this + " timeout: " + pingTimeout);
log.debug(this + " ping retries: " + configMap.get("NumberOfCallRetries"));
log.debug(this + " connection retries: " + configMap.get("NumberOfRetries"));
locator = client.getInvoker().getLocator();
@@ -471,7 +490,7 @@
}
catch (Exception e)
{
- log.error("Unable to create client invoker for locator: " + locator);
+ log.debug("Unable to create client invoker for locator: " + locator);
throw new RuntimeException("Unable to create client invoker for locator: " + locator, e);
}
@@ -483,7 +502,7 @@
TimerUtil.schedule(this, pingPeriod);
stopped = false;
-
+ timer = new Timer(true);
log.debug(this + " started");
}
@@ -518,7 +537,35 @@
return pingWorked;
}
+
+ private boolean doCheckConnectionWithoutLease() throws Throwable
+ {
+ boolean pingWorked = false;
+ try
+ {
+ // Sending null client id as don't want to trigger lease on server side. This also means
+ // that client connection validator will NOT impact client lease, so can not depend on it
+ // to maintain client lease with the server.
+ InvocationRequest ir =
+ new InvocationRequest(null, Subsystem.SELF, "$PING$", null, null, null);
+
+ if (trace) { log.trace("pinging, sending " + ir + " over " + clientInvoker); }
+
+ clientInvoker.invoke(ir);
+
+ if (trace) { log.trace("ConnectionValidator got successful ping using " + clientInvoker);}
+
+ pingWorked = true;
+ }
+ catch (Throwable t)
+ {
+ log.debug("ConnectionValidator failed to ping via " + clientInvoker, t);
+ }
+
+ return pingWorked;
+ }
+
private boolean doStop()
{
synchronized(lock)
@@ -569,4 +616,89 @@
// Inner classes --------------------------------------------------------------------------------
+ private class WaitOnConnectionCheckTimerTask extends TimerTask
+ {
+ public void run()
+ {
+ long start = System.currentTimeMillis();
+ synchronized (notificationLock)
+ {
+ while (true)
+ {
+ int elapsed = (int) (System.currentTimeMillis() - start);
+ int wait = pingTimeout - elapsed;
+ if (wait <= 0) break;
+
+ try
+ {
+ notificationLock.wait(wait);
+ break;
+ }
+ catch (InterruptedException e)
+ {
+ continue;
+ }
+ }
+ }
+
+ if (!isValid)
+ {
+ log.debug(ConnectionValidator.this + "'s connections is invalid");
+
+ notifyListeners(new Exception("Could not connect to server!"));
+
+ if (stopLeaseOnFailure)
+ {
+ log.debug(this + " detected connection failure: stopping LeasePinger");
+ MicroRemoteClientInvoker invoker = (MicroRemoteClientInvoker) client.getInvoker();
+
+ if (invoker != null)
+ {
+ invoker.terminateLease(null, client.getDisconnectTimeout());
+ log.debug(ConnectionValidator.this + " shut down lease pinger");
+ }
+ else
+ {
+ log.debug(ConnectionValidator.this + " unable to shut down lease pinger: client must have shut down");
+ }
+
+ cancel();
+ }
+ }
+ }
+ }
+
+ private static class ConnectionCheckThread extends Thread
+ {
+ private InvocationRequest ir;
+ private ClientInvoker clientInvoker;
+ private boolean isValid;
+
+ public ConnectionCheckThread(ClientInvoker clientInvoker, InvocationRequest ir)
+ {
+ this.clientInvoker = clientInvoker;
+ this.ir = ir;
+ setDaemon(true);
+ }
+
+ public void run()
+ {
+ try
+ {
+ if (trace) { log.trace("pinging, sending " + ir + " over " + clientInvoker); }
+ clientInvoker.invoke(ir);
+ isValid = true;
+ if (trace) { log.trace("ConnectionValidator got successful ping using " + clientInvoker);}
+ }
+ catch (Throwable t)
+ {
+ log.debug("ConnectionValidator failed to ping via " + clientInvoker, t);
+ }
+ }
+
+ public boolean isValid()
+ {
+ return isValid;
+ }
+ }
}
\ No newline at end of file
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4276 - remoting2/tags/2.4.0-GA/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-08 19:43:55 -0400 (Sun, 08 Jun 2008)
New Revision: 4276
Modified:
remoting2/tags/2.4.0-GA/docs/guide/en/chap10.xml
remoting2/tags/2.4.0-GA/docs/guide/en/chap12.xml
remoting2/tags/2.4.0-GA/docs/guide/en/chap15.xml
remoting2/tags/2.4.0-GA/docs/guide/en/chap7.xml
Log:
JBREM-987: Fixed screwed up chapters.
Modified: remoting2/tags/2.4.0-GA/docs/guide/en/chap10.xml
===================================================================
--- remoting2/tags/2.4.0-GA/docs/guide/en/chap10.xml 2008-06-08 23:33:38 UTC (rev 4275)
+++ remoting2/tags/2.4.0-GA/docs/guide/en/chap10.xml 2008-06-08 23:43:55 UTC (rev 4276)
@@ -1,2634 +1,19 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter>
- <title>How to use it - sample code</title>
+ <chapter>
+ <title>Transporters - beaming POJOs</title>
- <para>Sample code demonstrating different remoting features can be found in
- the examples directory. They can be compiled and run manually via your IDE
- or via an ant build file found in the examples directory. There are many
- sets of sample code, each with their own package. Within most of these
- packages, there will be a server and a client class that will need to be
- executed</para>
+ <para>There are many ways in which to expose a remote interface to a java
+ object. Some require a complex framework API based on a standard
+ specification and some require new technologies like annotations and AOP.
+ Each of these have their own benefits. JBoss Remoting transporters provide
+ the same behavior via a simple API without the need for any of the newer
+ technologies.</para>
- <section>
- <title>Simple invocation</title>
-
- <para>The simple invocation sample (found in the
- org.jboss.remoting.samples.simple package), has two classes; SimpleClient
- and SimpleServer. It demonstrates making a simple invocation from a
- remoting client to a remoting server. The SimpleClient class will create
- an InvokerLocator object from a simple url-like string that identifies the
- remoting server to call upon (which will be socket://localhost:5400 by
- default). Then the SimpleClient will create a remoting Client class,
- passing the newly created InvokerLocator. Next the Client will be called
- to make an invocation on the remoting server, passing the request payload
- object (which is a String with the value of "Do something"). The server
- will return a response from this call which is printed to standard
- output.</para>
-
- <para>Within the SimpleServer, a remoting server is created and started.
- This is done by first creating an InvokerLocator, just like was done in
- the SimpleClient. Then constructing a Connector, passing the
- InvokerLocator. Next, need to call create() on the Connector to initialize
- all the resources, such as the remoting server invoker. Once created, need
- to create the invocation handler. The invocation handler is the class that
- the remoting server will pass client requests on to. The invocation
- handler in this sample simply returns the simple String "This is the
- return to SampleInvocationHandler invocation". Once created, the handler
- is added to the Connector. Finally, the Connector is started and will
- start listening for incoming client requests.</para>
-
- <para>To run this example, can compile both the SimpleClient and
- SimpleServer class, then first run the SimpleServer and then the
- SimpleClient. Or can go to the examples directory and run the ant target
- 'run-simple-server' and then in another console window run the ant target
- 'run-simple-client'. For example:</para>
-
- <para><programlisting>ant run-simple-server</programlisting>ant
- then:</para>
-
- <para><programlisting>ant run-simple-client</programlisting>The output
- when running the SimpleClient should look like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400
-Invoking server with request of 'Do something'
-Invocation response: This is the return to SampleInvocationHandler invocation</programlisting>
-
- <para>The output when running the SimpleServer should look like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Invocation request is: Do something
-Returning response of: This is the return to SampleInvocationHandler invocation</programlisting>
-
- <para>Note: will have to manually shut down the SimpleServer once
- started.</para>
- </section>
-
- <section>
- <title>HTTP invocation</title>
-
- <para>This http invocation sample (found in the
- org.jboss.remoting.samples.http package), demonstrates how the http
- invoker can be used for a variety of http based invocations. This time,
- will start with the server side. The SimpleServer class is much like the
- one from the previous simple invocation example, except that instead of
- using the 'socket' transport, will be using the 'http' transport. Also,
- instead of using the SampleInvocationHandler class as the handler, will be
- using the WebInvocationHandler (code shown below).</para>
-
- <programlisting>public class <emphasis role="bold">WebInvocationHandler</emphasis> implements <emphasis
- role="bold">ServerInvocationHandler</emphasis>
-{
- // Pre-defined returns to be sent back to client based on type of request.
- public static final String RESPONSE_VALUE = "This is the return to simple text based http invocation.";
- public static final ComplexObject OBJECT_RESPONSE_VALUE = new ComplexObject(5, "dub", false);
- public static final String HTML_PAGE_RESPONSE = "<html><head><title>Test HTML page</title></head><body>" +
- "<h1>HTTP/Servlet Test HTML page</h1><p>This is a simple page served for test." +
- "<p>Should show up in browser or via invoker client</body></html>";
-
- // Different request types that client may make
- public static final String NULL_RETURN_PARAM = "return_null";
- public static final String OBJECT_RETURN_PARAM = "return_object";
- public static final String STRING_RETURN_PARAM = "return_string";
-
-
- /**
- * called to handle a specific invocation
- *
- * @param invocation
- * @return
- * @throws Throwable
- */
- <emphasis role="bold">public Object invoke(InvocationRequest invocation) throws Throwable
- {
- // Print out the invocation request
- System.out.println("Invocation request from client is: " + invocation.getParameter());
- if(NULL_RETURN_PARAM.equals(invocation.getParameter()))
- {
- return null;
- }
- else if(invocation.getParameter() instanceof ComplexObject)
- {
- return OBJECT_RESPONSE_VALUE;
- }
- else if(STRING_RETURN_PARAM.equals(invocation.getParameter()))
- {
- Map responseMetadata = invocation.getReturnPayload();
- responseMetadata.put(HTTPMetadataConstants.RESPONSE_CODE, new Integer(207));
- responseMetadata.put(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE, "Custom response code and message from remoting server");
- // Just going to return static string as this is just simple example code.
- return RESPONSE_VALUE;
- }
- else
- {
- return HTML_PAGE_RESPONSE;
- }</emphasis>
- }
-</programlisting>
-
- <para>The most interesting part of the WebInvocationHandler is its
- invoke() method implementation. First it will check to see what the
- request parameter was from the InvocationRequest and based on what the
- value is, will return different responses. The first check is to see if
- the client passed a request to return a null value. The second will check
- to see if the request parameter from the client was of type ComplexObject.
- If so, return the pre-built ComplexObject that was created as a static
- variable.</para>
-
- <para>After that, will check to see if the request parameter was for
- returning a simple String. Notice in this block, will set the desired
- response code and message to be returned to the client. In this case, are
- setting the response code to be returned to 207 and the response message
- to "Custom response code and message from remoting server". These are
- non-standard code and message, but can be anything desired.</para>
-
- <para>Last, if have not found a matching invocation request parameter,
- will just return some simple html.</para>
-
- <para>Now onto the client side for making the calls to this handler, which
- can be found in SimpleClient (code shown below).</para>
-
- <programlisting>public class <emphasis role="bold">SimpleClient</emphasis>
-{
- // Default locator values
- private static String transport = "<emphasis role="bold">http</emphasis>";
- private static String host = "localhost";
- private static int port = 5400;
-
- public void makeInvocation(String locatorURI) throws Throwable
- {
- // create InvokerLocator with the url type string
- // indicating the target remoting server to call upon.
- InvokerLocator locator = new InvokerLocator(locatorURI);
- System.out.println("Calling remoting server with locator uri of: " + locatorURI);
-
- Client remotingClient = new Client(locator);
-
- // make invocation on remoting server and send complex data object
- // by default, the remoting http client invoker will use method type of POST,
- // which is needed when ever sending objects to the server. So no metadata map needs
- // to be passed to the invoke() method.
- <emphasis role="bold">Object response = remotingClient.invoke(new ComplexObject(2, "foo", true), null);</emphasis>
-
- System.out.println("\nResponse from remoting http server when making http POST request and sending a complex data object:\n" + response);
-
-
- <emphasis role="bold">Map metadata = new HashMap();</emphasis>
- // set the metadata so remoting client knows to use http GET method type
- <emphasis role="bold">metadata.put("TYPE", "GET");</emphasis>
- // not actually sending any data to the remoting server, just want to get its response
- <emphasis role="bold">response = remotingClient.invoke((Object) null, metadata);</emphasis>
-
- System.out.println("\nResponse from remoting http server when making GET request:\n" + response);
-
- // now set type back to POST and send a plain text based request
- <emphasis role="bold">metadata.put("TYPE", "POST");</emphasis>
- <emphasis role="bold">response = remotingClient.invoke(WebInvocationHandler.STRING_RETURN_PARAM, metadata);</emphasis>
-
- System.out.println("\nResponse from remoting http server when making http POST request and sending a text based request:\n" + response);
-
- // notice are getting custom response code and message set by web invocation handler
- <emphasis role="bold">Integer responseCode = (Integer) metadata.get(HTTPMetadataConstants.RESPONSE_CODE);
- String responseMessage = (String) metadata.get(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE);</emphasis>
- System.out.println("Response code from server: " + responseCode);
- System.out.println("Response message from server: " + responseMessage);
-
- }
-</programlisting>
-
- <para>This SimpleClient, like the one before in the simple invocation
- example, starts off by creating an InvokerLocator and remoting Client
- instance, except is using http transport instead of socket. The first
- invocation made is to send a newly constructed ComplexObject. If remember
- from the WebInvocationHandler above, will expect this invocation to return
- a different ComplexObject, which can be seen in the following system
- output line.</para>
-
- <para>The next invocation to be made is a simple http GET request. To do
- this, must first let the remoting client know that the method type needs
- to be changed from the default, which is POST, to be GET. Then make the
- invocation with a null payload (since not wanting to send any data, just
- get data in response) and the metadata map just populated with the GET
- type. This invocation request will return a response of html.</para>
-
- <para>Then, will change back to being a POST type request and will pass a
- simple String as the payload to the invocation request. This will return a
- simple String as the response from the WebInvocationHandler. Afterward,
- will see the specific response code and message printed to standard
- output, as well as the exception itself.</para>
-
- <para>To run this example, can compile all the classes in the package,
- then first run the SimpleServer and then the SimpleClient. Or can go to
- the examples directory and run the ant target 'run-http-server' and then
- in another console window run the ant target 'run-http-client'. For
- example:</para>
-
- <programlisting>ant run-http-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-http-client</programlisting>
-
- <para>The output when running the SimpleClient should look like:</para>
-
- <programlisting>Response from remoting http server when making http POST request and sending a complex data object:
-ComplexObject (i = 5, s = dub, b = false, bytes.length = 0)
-
-Response from remoting http server when making GET request:
-<html><head><title>Test HTML page</title></head><body><h1>HTTP/Servlet Test HTML page</h1><p>This is a simple page served for test.<p>Should show up in browser or via invoker client</body></html>
-
-Response from remoting http server when making http POST request and sending a text based request:
-This is the return to simple text based http invocation.
-Response code from server: 207
-Response message from server: Custom response code and message from remoting server</programlisting>
-
- <para>Notice that the first response is the ComplexObject from the static
- variable returned within WebInvocationHandler. The next response is html
- and then simple text from the WebInvocationHandler. Can see the specific
- response code and message set in the WebInvocationHandler.</para>
-
- <para>The output from the SimpleServer should look like:</para>
-
- <programlisting>Starting remoting server with locator uri of: http://localhost:5400
-Jan 26, 2006 11:39:53 PM org.apache.coyote.http11.Http11BaseProtocol init
-INFO: Initializing Coyote HTTP/1.1 on http-127.0.0.1-5400
-Jan 26, 2006 11:39:53 PM org.apache.coyote.http11.Http11BaseProtocol start
-INFO: Starting Coyote HTTP/1.1 on http-127.0.0.1-5400
-Invocation request from client is: ComplexObject (i = 2, s = foo, b = true, bytes.length = 0)
-Invocation request from client is: null
-Invocation request from client is: return_string</programlisting>
-
- <para>First the information for the http server invoker is written, which
- includes the locator uri used to start the server and the output from
- starting the Tomcat connector. Then will see the invocation parameter
- passed for each client request.</para>
-
- <para>Since the SimpleServer should still be running, can open a web
- browser and enter the locator uri, http://localhost:5400. This should
- cause the browser to render the html returned from the
- WebInvocationHandler.</para>
- </section>
-
- <section>
- <title>Oneway invocation</title>
-
- <para>The oneway invocation sample (found in the
- org.jboss.remoting.samples.oneway package) is very similar to the simple
- invocation example, except in this sample, the client will make
- asynchronous invocations on the server.</para>
-
- <para>The OnewayClient class sets up the remoting client as in the simple
- invocation sample, but instead of using the invoke() method, it uses the
- invokeOneway() method on the Client class. There are two basic modes when
- making a oneway invocation in remoting. The first is to have the calling
- thread to be the one that makes the actual call to the server. This allows
- the caller to ensure that the invocation request at least made it to the
- server. Once the server receives the invocation request, the call will
- return (and the request will be processed by a separate worker thread on
- the server). The other mode, which is demonstrated in the second call to
- invokeOneway, allows for the calling thread to return immediately and a
- worker thread on the client side will make the actual invocation on the
- server. This is faster of the two modes, but if there is a problem making
- the request on the server, the original caller will be unaware.</para>
-
- <para>The OnewayServer is exactly the same as the SimpleServer from the
- previous example, with the exception that invocation handler returns null
- (since even if did return a response, would not be delivered to the
- original caller).</para>
-
- <para>To run this example, can compile both the OnewayClient and
- OnewayServer class, then run the OnewayServer and then the OnewayClient.
- Or can go to the examples directory and run the ant target
- 'run-oneway-server' and then in another console window run the ant target
- 'run-oneway-client'. For example:</para>
-
- <programlisting>ant run-oneway-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-oneway-client</programlisting>
-
- <para>The output when running the OnewayClient should look like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400
-Making oneway invocation with payload of 'Oneway call 1.'
-Making oneway invocation with payload of 'Oneway call 2.'</programlisting>
-
- <para>The output when running the OnewayServer should look like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Invocation request is: Oneway call 1.
-Invocation request is: Oneway call 2.</programlisting>
-
- <para>Note: will have to manually shut down the OnewayServer once
- started.</para>
-
- <para>Although this example only demonstrates making one way invocations,
- could include this with callbacks (see further down) to have asynchronous
- invocations with callbacks to verify was processed.</para>
- </section>
-
- <section>
- <title>Discovery and invocation</title>
-
- <para>The discovery sample (found in the
- org.jboss.remoting.samples.detection package) is similar to the simple
- invocation example in that it makes a simple invocation from the client to
- the server. However, in this example, instead of explicitly specifying the
- invoker locator to use for the target remoting server, it is discovered
- dynamically during runtime. This example is composed of two classes;
- SimpleDetectorClient and SimpleDetectorServer.</para>
-
- <para>The SimpleDetectorClient starts off by setting up the remoting
- detector. Detection on the client side requires a few components; a JMX
- MBeanServer, one or more Detectors, and a NetworkRegistry. The Detectors
- will listen for detection messages from remoting servers and then add the
- information for the detected servers to the NetworkRegistry. They use JMX
- to lookup and call on the NetworkRegistry. The NetworkRegistry uses JMX
- Notifications to emit changes in network topology (remoting servers being
- added or removed).</para>
-
- <para>In this particular example, the SimpleDetectorClient is registered
- with the NetworkRegistry as a notification listener. When it receives
- notifications from the NetworkRegistry (via the handleNotification()
- method), it will check to see if the notification is for adding or
- removing a remoting server. If it is for adding a remoting server, the
- SimpleDetectorClient will get the array of InvokerLocators from the
- NetworkNotification and make a remote call for each. If the notification
- is for removing a remoting server, the SimpleDetectorClient will simply
- print out a message saying which server has been removed.</para>
-
- <para>The biggest change between the SimpleDetectorServer and the
- SimpleServer from the first sample is that have added a method,
- setupDetector(), to create and start a remoting Detector. On the server
- side, only two components are needed for detection; the Detector and a JMX
- MBeanServer. As for the setup of the Connector, it is exactly the same as
- before. Notice that even though we have added a Detector on the server
- side, the Connector is not directly aware of either Detector or the
- MBeanServer, so no code changes for the Connector setup is
- required.</para>
-
- <para>To run this example, can compile both the SimpleDetectorClient and
- SimpleDetectorServer class, then run the SimpleDetectorServer and then the
- SimpleDetectorClient. Or can go to the examples directory and run the ant
- target 'run-detector-server' and then in another window run the ant target
- 'run-detector-client'. For example:</para>
-
- <programlisting>ant run-detector-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-detector-client</programlisting>
-
- <para>The initial output when running the SimpleDetectorClient should look
- like:</para>
-
- <programlisting>ri Jan 13 09:36:50 EST 2006: [CLIENT]: Starting JBoss/Remoting client... to stop this client, kill it manually via Control-C
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: NetworkRegistry has been created
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: NetworkRegistry has added the client as a listener
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: MulticastDetector has been created and is listening for new NetworkRegistries to come online
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: GOT A NETWORK-REGISTRY NOTIFICATION: jboss.network.server.added
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: New server(s) have been detected - getting locators and sending welcome messages
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: Sending welcome message to remoting server with locator uri of: socket://127.0.0.1:5400/
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: The newly discovered server sent this response to our welcome message: Received your welcome message. Thank you!</programlisting>
-
- <para>The output when running the SimpleDetectorServer should look
- like:</para>
-
- <programlisting>Fri Jan 13 09:36:46 EST 2006: [SERVER]: Starting JBoss/Remoting server... to stop this server, kill it manually via Control-C
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: This server's endpoint will be: socket://localhost:5400
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: MulticastDetector has been created and is listening for new NetworkRegistries to come online
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: Starting remoting server with locator uri of: socket://localhost:5400
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: Added our invocation handler; we are now ready to begin accepting messages from clients
-Fri Jan 13 09:36:50 EST 2006: [SERVER]: RECEIVED A CLIENT MESSAGE: Welcome Aboard!
-Fri Jan 13 09:36:50 EST 2006: [SERVER]: Returning the following message back to the client: Received your welcome message. Thank you!</programlisting>
-
- <para>At this point, try stopping the SimpleDetectorServer (notice that
- the SimpleDetectorClient should still be running). After a few seconds,
- the client detector should detect that the server is no longer available
- and will see something like the following appended in the
- SimpleDetectorClient console window:</para>
-
- <programlisting>Fri Jan 13 09:37:04 EST 2006: [CLIENT]: GOT A NETWORK-REGISTRY NOTIFICATION: jboss.network.server.removed
-Fri Jan 13 09:37:04 EST 2006: [CLIENT]: It has been detected that a server has gone down with a locator of: InvokerLocator [socket://127.0.0.1:5400/]</programlisting>
- </section>
-
- <section>
- <title>Callbacks</title>
-
- <para>The callback sample (found in the
- org.jboss.remoting.samples.callback package) illustrates how to perform
- callbacks from a remoting server to a remoting client. This example is
- composed of two classes; CallbackClient and CallbackServer.</para>
-
- <para>Within remoting, there are two approaches in which a callback can be
- received. The first is to actively ask for callback messages from the
- remoting server, which is called a pull callback (since are pulling the
- callbacks from the server). The second is to have the server send the
- callbacks to the client as they are generated, which is called a push
- callback. This sample demonstrates how to do both pull and push
- callbacks.</para>
-
- <para>Looking at the CallbackClient class, will see that the first thing
- done is to create a remoting Client, which is done in the same manner as
- previous examples. Next, we'll perform a pull callback, which requires the
- creation of a CallbackHandler. The CallbackHandler, which implements the
- InvokerCallbackHandler interface, is what is called upon with a Callback
- object when a callback is received. The Callback object contains
- information such as the callback message (in Object form), the server
- locator from where the callback originally came from, and a handle object
- which can help to identify callback context (similar to the handle object
- within a JMX Notification). Once created, the CallbackHandler is then
- registered as a listener within the Client. This will cause the client to
- make a call to the server to notify the server it has a callback listener
- (more on this below in the server section). Although the CallbackHandler
- is not called upon directly when doing pull callbacks, it is needed as an
- identifier for the callbacks.</para>
-
- <para>Then the client will wait a few seconds, make a simple invocation on
- the server, and then call on the remoting Client instance to get any
- callbacks that may be available for our CallbackHandler. This will return
- a list of callbacks, if any exist. The list will be iterated and each
- callback will be printed to standard output. Finally, the callback handler
- will be removed as a listener from the remoting Client (which in turns
- removes it from the remoting server).</para>
-
- <para>After performing a pull callback, will perform a push callback. This
- is a little more involved as requires creating a callback server to which
- the remoting target server can callback on when it generates a callback
- message. To do this, will need to create a remoting Connector, just as
- have seen in previous examples. For this particular example, we use the
- same locator url as our target remoting server, but increment the port to
- listen on by one. Will also notice that use the SampleInvocationHandler
- hander from the CallbackServer (more in this in a minute). After creating
- our callback server, a CallbackHandler and callback handle object is
- created. Next, remoting Client is called to add our callback listener.
- Here we pass not only the CallbackHandler, but the InvokerLocator for the
- callback server (so the target server will know where to deliver callback
- messages to), and the callback handle object (which will be included in
- all the callback messages delivered for this particular callback
- listener).</para>
-
- <para>Then the client will wait a few seconds, to allow the target server
- time to generate and deliver callback messages. After that, we remove the
- callback listener and clean up our callback server.</para>
-
- <para>The CallbackServer is pretty much the same as the previous samples
- in setting up the remoting server, via the Connector. The biggest change
- resides in the ServerInvocationHandler implementation,
- SampleInvocationHandler (which is an inner class to CallbackServer). The
- first thing to notice is now have a variable called listeners, which is a
- List to hold any callback listeners that get registered. Also, in the
- constructor of the SampleInvocationHandler, we set up a new thread to run
- in the background. This thread, executing the run() method in
- SampleInvocationHandler, will continually loop looking to see if the
- shouldGenerateCallbacks has been set. If it has been, will create a
- Callback object and loop through its list of listeners and tell each
- listener to handle the newly created callback. Have also added
- implementation to the addListener() and removeListener() methods where
- will either add or remove specified callback listener from the internal
- callback listener list and set the shouldGenerateCallbacks flag
- accordingly. The invoke() method remains the same as in previous
- samples.</para>
-
- <para>To run this example, can compile both the CallbackClient and
- CallbackServer class, then run the CallbackServer and then the
- CallbackClient. Or can go to the examples directory and run the ant target
- 'run-callback-server' and then in another window run the ant target
- 'run-callback-client. For example:</para>
-
- <programlisting>ant run-callback-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-callback-client</programlisting>
-
- <para>The output in the CallbackClient console window should look
- like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400
-Invocation response: This is the return to SampleInvocationHandler invocation
-Pull Callback value = Callback 1: This is the payload of callback invocation.
-Pull Callback value = Callback 2: This is the payload of callback invocation.
-Starting remoting server with locator uri of: InvokerLocator [socket://127.0.0.1:5401/]
-Received push callback.
-Received callback value of: Callback 3: This is the payload of callback invocation.
-Received callback handle object of: myCallbackHandleObject
-Received callback server invoker of: InvokerLocator [socket://127.0.0.1:5400/]
-Received push callback.
-Received callback value of: Callback 4: This is the payload of callback invocation.
-Received callback handle object of: myCallbackHandleObject
-Received callback server invoker of: InvokerLocator [socket://127.0.0.1:5400/]</programlisting>
-
- <para>This output shows that client first pulled two callbacks generated
- from the server. Then, after creating and registering our second callback
- handler and a callback server, two callbacks were received from the target
- server.</para>
-
- <para>The output in the CallbackServer console window should look
- like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Adding callback listener.
-Invocation request is: Do something
-Removing callback listener.
-Adding callback listener.
-Removing callback listener. </programlisting>
-
- <para>This output shows two distinct callback handlers being added and
- removed (with an invocation request being received after the first was
- added).</para>
-
- <para>There are a few important points to mention about this example.
- First, notice that in the client, the same callback handle object in the
- push callbacks was received as was registered with the callback listener.
- However, there was no special code required to facilitate this within the
- SampleInvocationHandler. This is handled within remoting automatically.
- Also notice when the callback server was created within the client, no
- special coding was required to register the callback handler with it, both
- were simply passed to the remoting Client instance when registering the
- callback listener and was handled internally.</para>
- </section>
-
- <section>
- <title>Streaming</title>
-
- <para>The streaning sample (found in the org.jboss.remoting.samples.stream
- package) illustrates how a java.io.InputStream can be sent from a client
- and read on demand from a server. This example is composed of two classes:
- StreamingClient and StreamingServer.</para>
-
- <para>Unlike the previous examples that sent plain old java objects as the
- payload, this example will be sending a java.io.FileInputStream as the
- payload to the server. This is a special case because streams can not be
- serialized. One approach to this might be to write out the contents of a
- stream to a byte buffer and send the whole data content to the server.
- However, this approach can be dangerous because if the data content of the
- stream is large, such as an 800MB file, would run the risk of causing an
- out of memory error (since are loading all 800MB into memory). Another
- approach, which is used by JBossRemoting, is to create a proxy to the
- original stream. This proxy can then be called upon for reading, same as
- the original stream. When this happens, the proxy will call back the
- original stream for the requested data.</para>
-
- <para>Looking at the StreamingClient, the remoting Client is created as in
- previous samples. Next, will create a java.io.FileInputStream to the
- sample.txt file on disk (which is in the same directory as the test
- classes). Finally, will call the remoting Client to do its invocation,
- passing the new FileInputStream and the name of the file. The second
- parameter could be of any Object type and is meant to supply some
- meaningful context to the server in regards to the stream being passed,
- such as the file name to use when writing to disk on the server side. The
- response from the server, in this example, is the size of the file it
- wrote to disk.</para>
-
- <para>The StreamingServer sets up the remoting server as was done in
- previous examples. However, instead of using an implementation of the
- ServerInvocationHandler class as the server handler, an implementation of
- the StreamInvocationHandler (which extends the ServerInvocationHandler) is
- used. The StreamInvocationHandler includes an extra method called
- handleStream() especially for processing requests with a stream as the
- payload. In this example, the class implementing the
- StreamInvocationHandler is the TestStreamInvocationHandler class, which is
- an inner class to the StreamingServer. The handleStream() method within
- the TestStreamInvocationHandler will use the stream passed to it to write
- out its contents to a file on disk, as specified by the second parameter
- passed to the handleStream() method. Upon writing out the file to disk,
- the handleStream() method will return to the client caller the size of the
- file.</para>
-
- <para>To run this example, can compile both the StreamingClient and
- StreamingServer class, then run the StreamingServer and then the
- StreamingClient. Or can go to the examples directory and run the ant
- target 'run-stream-server' and then in another window run the ant target
- 'run-stream-client'. For example:</para>
-
- <programlisting>ant run-stream-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-stream-client</programlisting>
-
- <para>The output in the StreamingClient console window should look
- like:</para>
-
- <programlisting>Calling on remoting server with locator uri of: socket://localhost:5400
-Sending input stream for file sample.txt to server.
-Size of file sample.txt is 987
-Server returned 987 as the size of the file read.</programlisting>
-
- <para>The output in the StreamingServer console window should look
- like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Received input stream from client to write out to file server_sample.txt
-Read stream of size 987. Now writing to server_sample.txt
-New file server_sample.txt has been written out to C:\tmp\JBossRemoting_1_4_0_final\examples\server_sample.txt</programlisting>
-
- <para>After running this example, there should be a newly created
- server_sample.txt file in the root examples directory. The contents of the
- file should look exactly like the contents of the sample.txt file located
- in the examples\org\jboss\remoting\samples\stream directory.</para>
- </section>
-
- <section>
- <title>JBoss Serialization</title>
-
- <para>The serialization sample (found in the
- org.jboss.remoting.samples.serialization package) illustrates how JBoss
- Serialization can be used in place of the standard java serialization to
- allow for sending of invocation payload objects that do not implement the
- java.io.Serializable interface. This example is composed of three classes:
- SerializationClient, SerializationServer, and
- NonSerializablePayload.</para>
-
- <para>This example is exactly like the one from the simple example with
- two differences. The first difference is the use of JBoss Serialization to
- convert object instances to binary data format for wire transfer. This is
- accomplished by adding an extra parameter (serializationtype) to the
- locator url with a value of 'jboss'. Is important to note that use of
- JBoss Serialization requires JDK 1.5, so this example will need to be run
- using JDK 1.5. The second difference is instead of sending and receiving a
- simple String type for the remote invocation payload, will be sending and
- receiving an instance of the NonSerializablePayload class.</para>
-
- <para>There are a few important points to notice with the
- NonSerializablePayload class. The first is that it does NOT implement the
- java.io.Serializable interface. The second is that it has a void parameter
- constructor. This is a requirement of JBoss Serialization for object
- instances that do not implement the Serializable interface. However, this
- void parameter constructor can be private, as in the case of
- NonSerializablePayload, as to not change the external API of the
- class.</para>
-
- <para>To run this example, can compile both the SerializationClient and
- SerializationServer class, then run the SerializationServer and then the
- SerializationClient. Or can go to the examples directory and run the ant
- target 'run-serialization-server' and then in another window run the ant
- target 'run-serialization-client'. For example:</para>
-
- <programlisting>ant run-serialization-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-serialization-client</programlisting>
-
- <para>The output in the SerializationClient console window should look
- like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400/?serializationtype=jboss
-Invoking server with request of 'NonSerializablePayload - name: foo, id: 1'
-Invocation response: NonSerializablePayload - name: bar, id: 2</programlisting>
-
- <para>The output in the SerializationServer console window should look
- like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400/?serializationtype=jboss
-Invocation request is: NonSerializablePayload - name: foo, id: 1
-Returning response of: NonSerializablePayload - name: bar, id: 2</programlisting>
-
- <para>Note: will have to manually shut down the SerializationServer once
- started.</para>
- </section>
-
- <section>
- <title>Transporters</title>
-
- <section>
- <title>Transporters - beaming POJOs</title>
-
- <para>There are many ways in which to expose a remote interface to a
- java object. Some require a complex framework API based on a standard
- specification and some require new technologies like annotations and
- AOP. Each of these have their own benefits. JBoss Remoting transporters
- provide the same behavior via a simple API without the need for any of
- the newer technologies.</para>
-
- <para>When boiled down, transporters take a plain old java object (POJO)
- and expose a remote proxy to it via JBoss Remoting. Dynamic proxies and
- reflection are used to make the typed method calls on that target POJO.
- Since JBoss Remoting is used, can select from a number of different
- network transports (i.e. rmi, http, socket, multiplex, etc.), including
- support for SSL. Even clustering features can be included.</para>
-
- <bridgehead>How it works</bridgehead>
-
- <para>In this section will discuss how remoting transporters can be
- used, some requirments for usage, and a little detail on the
- implementation. For greater breath on usage, please review the
- transporter samples as most use cases are covered there.</para>
-
- <para>To start, will need to have a plain old java object that
- implements one or more interfaces that want to expose for remote method
- invocation. Then will need to create a
- <code>org.jboss.remoting.transporter.TransporterServer</code> to wrap
- around it, so that can be exposed remotely. This can be done in one of
- two basic ways. The first is to use a static
- <code>createTransporterServer()</code> method of the TransporterServer
- class. There are many of these create methods, but all basically do that
- same thing in that they take a remoting locator and target pojo and will
- return a TransporterServer instance that has been started and ready to
- receive remote invocations (see javadoc for TransporterServer for all
- the different static createTransporterServer() methods). The other way
- to create a TransporterServer for the target pojo is to construct an
- instance of it. This provides a little more flexibility as are able to
- control more aspects of the TransporterServer, such as when it will be
- started.</para>
-
- <para>When a TransporterServer is created, it will create a remoting
- Connector using the locator provided. It will generate a server
- invocation handler that wraps the target pojo provided and use
- reflection to make the calls on it based on the invocations it receives
- from clients. By default, the subsystem underwhich the server invocation
- handler is registered is the interface class name for which the target
- pojo is exposing. If the target implements multiple interfaces, and a
- specific one to use is not specified, all the interfaces will be
- registered as subsystems for the same server invocation handler.
- Whenever no long want the target pojo to receive remote method
- invocations, will need to call the <code>stop()</code> method on the
- TransporterServer for the target pojo (this is very important, as
- otherwise will never be released from memory and will continue to
- consume network and memory resources).</para>
-
- <para>On the client side, in order to be able to call on the target pojo
- remotely, will need to use the
- <code>org.jboss.remoting.transporter.TransporterClient</code>. Unlike
- the TransporterServer, can only use the static create methods of the
- TransporterClient (this is because the return to the static create
- method is a typed dynamic proxy). The static method to call on the
- TransportClient is <code>createTransporterClient()</code>, where will
- pass the locator to find the target pojo (same as one used when creating
- the TransporterServer) and the interface for the target pojo that want
- to make remote method invocations on. The return from this create call
- will be a dynamic proxy which you can cast to to same interface type
- supplied. At that point, can make typed method invocations on the
- returned object, which will then make the remote invocations under the
- covers. Note that can have multiple transporter clients to the same
- target pojo, each using different interface types for making
- calls.</para>
-
- <para>When no longer need to make invocations on the target pojo, the
- resources associated with the remoting client will need to be cleaned
- up. This is done by calling the <code>destroyTransporterClient()</code>
- method of the TransporterClient. This is important to remember to do, as
- will otherwise leave network resources active even though not in
- use.</para>
-
- <para>One of the features of using remoting transporters is location
- transparency. By this mean that client proxies returned by the
- TransporterClient can be passed over the network. For example, can have
- a target pojo that returns from a method call a client proxy (that it
- created using the TransporterClient) in which the client can call on
- directly as well. See the transporter proxy sample code to see how this
- can be done.</para>
-
- <para>Another nice feature when using transporters is the ability to
- cluster. To be more specific, can create multiple target pojos using the
- TransporterServer in clustered mode and then use the TransporterClient
- in clustered mode to create a client proxy that will discover the
- location of the target pojos are wanting to call on. Will also provide
- automatic, seemless failover of remote method invocations in the case
- that a particular target pojo instance fails. However, note that only
- provide invocation failover and does not take into account state
- transfer between target pojos (would need addition of JBoss Cache or
- some other state synchronization tool).</para>
- </section>
-
- <para>The transporter sample spans several examples showing different ways
- to use the transporter. Each specific example is within its own package
- under the org.jboss.remoting.samples.transporter package. Since each of
- the transporter examples includes common objects, as well as client and
- server classes, the common objects will be found under the main
- transporter sub-package and the client and server classes in their
- respective sub-packages (named client and server).</para>
-
- <section>
- <title>Transporters sample - simple</title>
-
- <para>The simple transporter example (found in
- org.jboss.remoting.samples.transporter.simple package) demonstrates a
- very simple example of how to use the transporters to expose a plain old
- java object for remote method invocations.</para>
-
- <para>In this simple transporter example, will be taking a class that
- formats a java.util.Date into a simple String representation and
- exposing it so can call on the remotely. The target object in this case,
- org.jboss.remoting.samples.transporter.simple.DateProcessorImpl,
- implements the
- org.jboss.remoting.samples.transporter.simple.DateProcessor interfaces
- (as shown below):</para>
-
- <programlisting>public interface DateProcessor
-{
- public String formatDate(Date dateToConvert);
-}
-
-
-public class DateProcessorImpl implements DateProcessor
-{
- public String formatDate(Date dateToConvert)
- {
- DateFormat dateFormat = DateFormat.getDateInstance(DateFormat.MEDIUM);
- return dateFormat.format(dateToConvert);
- }
-}</programlisting>
-
- <para>This is then exposed using the TransporterServer by the
- org.jboss.remoting.samples.transporter.simple.Server class.</para>
-
- <programlisting>public class Server
-{
- public static void main(String[] args) throws Exception
- {
- TransporterServer server = TransporterServer.createTransporterServer("socket://localhost:5400", new DateProcessorImpl(), DateProcessor.class.getName());
- Thread.sleep(10000);
- server.stop();
- }
-}</programlisting>
-
- <para>The Server class simply creates a TransporterServer by indicating
- the locator url would like to use for the remoting server, a newly
- created instance of DataProcessorImpl, and the interface type would like
- to expose remotely. The TransporterServer returned from the
- createTransporterServer call is live and ready to receive incoming
- method invocation requests. Will then wait 10 seconds for a request,
- then stop the server.</para>
-
- <para>Next need to have client to make the remote invocation. This can
- be found within
- org.jboss.remoting.samples.transporter.simple.Client.</para>
-
- <programlisting>public class Client
-{
- public static void main(String[] args) throws Exception
- {
- DateProcessor dateProcessor = (DateProcessor) TransporterClient.createTransporterClient("socket://localhost:5400", DateProcessor.class);
- String formattedDate = dateProcessor.formatDate(new Date());
- System.out.println("Current date: " + formattedDate);
- }
-}</programlisting>
-
- <para>In the Client class, create a TransporterClient which can be cast
- to the desired type, which is DataProcessor in this case. In calling the
- createTransporterClient, need to specify the locator ulr (same as was
- used for the TransporterServer), and the interface type will be calling
- on for the target pojo. Once have the DateProcessor variable, will make
- the call to formatDate() and pass a newly created Date object. The
- return will be a formated String of the date passed.</para>
-
- <para>To run this example, can run the Server and then the Client. Or
- can go to the examples directory and run the ant target
- 'run-transporter-simple-server' and then in another window run the ant
- target 'run-transporter-simple-client'. For example:</para>
-
- <programlisting>ant run-transporter-simple-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-simple-client</programlisting>
-
- <para>The output from the client window should look similar to:</para>
-
- <programlisting>Current date: Jul 31, 2006</programlisting>
- </section>
-
- <section>
- <title>Transporter sample - basic</title>
-
- <para>The basic transporter example (found in
- org.jboss.remoting.samples.transporter.basic package) illustrates how to
- build a simple transporter for making remote invocations on plain old
- java objects.</para>
-
- <para>In this basic transporter example, will be using a few domain
- objects; <code>Customer</code> and Address, which are just data
- objects.</para>
-
- <programlisting>public class <emphasis role="bold">Customer</emphasis> implements Serializable
-{
- private String firstName = null;
- private String lastName = null;
- private Address addr = null;
- private int customerId = -1;
-
- public String getFirstName()
- {
- return firstName;
- }
-
- public void setFirstName(String firstName)
- {
- this.firstName = firstName;
- }
-
- public String getLastName()
- {
- return lastName;
- }
-
- public void setLastName(String lastName)
- {
- this.lastName = lastName;
- }
-
- public Address getAddr()
- {
- return addr;
- }
-
- public void setAddr(Address addr)
- {
- this.addr = addr;
- }
-
- public int getCustomerId()
- {
- return customerId;
- }
-
- public void setCustomerId(int customerId)
- {
- this.customerId = customerId;
- }
-
- public String toString()
- {
- StringBuffer buffer = new StringBuffer();
- buffer.append("\nCustomer:\n");
- buffer.append("customer id: " + customerId + "\n");
- buffer.append("first name: " + firstName + "\n");
- buffer.append("last name: " + lastName + "\n");
- buffer.append("street: " + addr.getStreet() + "\n");
- buffer.append("city: " + addr.getCity() + "\n");
- buffer.append("state: " + addr.getState() + "\n");
- buffer.append("zip: " + addr.getZip() + "\n");
-
- return buffer.toString();
- }
-}</programlisting>
-
- <programlisting>public class <emphasis role="bold">Address</emphasis> implements Serializable
-{
- private String street = null;
- private String city = null;
- private String state = null;
- private int zip = -1;
-
- public String getStreet()
- {
- return street;
- }
-
- public void setStreet(String street)
- {
- this.street = street;
- }
-
- public String getCity()
- {
- return city;
- }
-
- public void setCity(String city)
- {
- this.city = city;
- }
-
- public String getState()
- {
- return state;
- }
-
- public void setState(String state)
- {
- this.state = state;
- }
-
- public int getZip()
- {
- return zip;
- }
-
- public void setZip(int zip)
- {
- this.zip = zip;
- }
-}</programlisting>
-
- <para>Next comes the POJO that we want to expose a remote proxy for,
- which is <code>CustomerProcessorImpl</code> class. This implementation
- has one method to process a <code>Customer</code> object. It also
- implements the <code>CustomerProcessor</code> interface.</para>
-
- <programlisting>public class <emphasis role="bold">CustomerProcessorImpl</emphasis> implements <emphasis
- role="bold">CustomerProcessor</emphasis>
-{
- /**
- * Takes the customer passed, and if not null and customer id
- * is less than 0, will create a new random id and set it.
- * The customer object returned will be the modified customer
- * object passed.
- *
- * @param customer
- * @return
- */
- public Customer processCustomer(Customer customer)
- {
- if(customer != null && customer.getCustomerId() < 0)
- {
- customer.setCustomerId(new Random().nextInt(1000));
- }
- System.out.println("processed customer with new id of " + customer.getCustomerId());
- return customer;
- }
-}</programlisting>
-
- <programlisting>public interface <emphasis role="bold">CustomerProcessor</emphasis>
-{
- /**
- * Process a customer object. Implementors
- * should ensure that the customer object
- * passed as parameter should have its internal
- * state changed somehow and returned.
- *
- * @param customer
- * @return
- */
- public Customer processCustomer(Customer customer);
-}</programlisting>
-
- <para>So far, nothing special, just plain old java objects. Next need to
- create the server component that will listen for remote request to
- invoke on the target POJO. This is where the transporter comes
- in.</para>
-
- <programlisting>public class <emphasis role="bold">Server</emphasis>
-{
- private String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = <emphasis role="bold">TransporterServer.createTransporterServer(locatorURI, new CustomerProcessorImpl())</emphasis>;
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The <code>Server</code> class is a pretty simple one. It calls the
- <code>TransporterServer</code> factory method to create the server
- component for the <code>CustomerProcessorImpl</code> instance using the
- specified remoting locator information.</para>
-
- <para>The <code>TransporterServer</code> returned from the
- <code>createTransporterServer() </code>call will be a running instance
- of a remoting server using the <literal>socket</literal> transport that
- is bound to <literal>localhost</literal> and listening for remote
- requests on port <literal>5400</literal>. The requests that come in will
- be forwarded to the remoting handler which will convert them into direct
- method calls on the target POJO, <code>CustomerProcessorImpl</code> in
- this case, using reflection.</para>
-
- <para>The <code>TransporterServer</code> has a <code>start()</code> and
- <code>stop()</code> method exposed to control when to start and stop the
- running of the remoting server. The <code>start()</code> method is
- called automatically within the <code>createTransporterServer()</code>
- method, so is ready to receive requests upon the return of this method.
- The <code>stop()</code> method, however, needs to be called explicitly
- when no longer wish to receive remote calls on the target POJO.</para>
-
- <para>Next up is the client side. This is represented by the
- <code>Client</code> class.</para>
-
- <programlisting>public class <emphasis role="bold">Client</emphasis>
-{
- private String locatorURI = "socket://localhost:5400";
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- <emphasis role="bold">CustomerProcessor customerProcessor = (CustomerProcessor) TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class);</emphasis>
-
- System.out.println("Customer to be processed: " + customer);
- <emphasis role="bold">Customer processedCustomer = customerProcessor.processCustomer(customer);</emphasis>
- System.out.println("Customer is now: " + processedCustomer);
-
- <emphasis role="bold">TransporterClient.destroyTransporterClient(customerProcessor);</emphasis>
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanata");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
- client.makeClientCall();
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-}</programlisting>
-
- <para>The <code>Client</code> class is also pretty simple. It creates a
- new <code>Customer</code> object instance, creates the remote proxy to
- the <code>CustomerProcessor</code>, and then calls on the
- <code>CustomerProcessor</code> to process its new <code>Customer</code>
- instance.</para>
-
- <para>To get the remote proxy for the <code>CustomerProcessor</code>,
- all that is required is to call the <code>TransporterClient</code>'s
- method <code>createTransporterClient()</code> method and pass the
- locator uri and the type of the remote proxy (and explicitly cast the
- return to that type). This will create a dynamic proxy for the specified
- type, <code>CustomerProcessor</code> in this case, which is backed by a
- remoting client which in turn makes the calls to the remote POJO's
- remoting server. Once the call to <code>createTransportClient()</code>
- has returned, the remoting client has already made its connection to the
- remoting server and is ready to make calls (will throw an exception if
- it could not connect to the specified remoting server).</para>
-
- <para>When finished making calls on the remote POJO proxy, will need to
- explicitly destroy the client by calling
- <code>destroyTransporterClient()</code> and pass the remote proxy
- instance. This allows the remoting client to disconnect from the POJO's
- remoting server and clean up any network resources previously
- used.</para>
-
- <para>To run this example, can run the Server and then the Client. Or
- can go to the examples directory and run the ant target
- 'run-transporter-basic-server' and then in another window run the ant
- target 'run-transporter-basic-client'. For example:</para>
-
- <programlisting>ant run-transporter-basic-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-basic-client</programlisting>
-
- <para>The output from the Client console should be similar to:</para>
-
- <programlisting>Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 204
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-</programlisting>
-
- <para>and the output from the Server class should be similar to:</para>
-
- <programlisting>processed customer with new id of 204</programlisting>
-
- <para>The output shows that the <code>Customer</code> instance created
- on the client was sent to the server where it was processed (by setting
- the customer id to 204) and returned to the client (and printed out
- showing that the customer id was set to 204).</para>
- </section>
-
- <section>
- <title>Transporter sample - JBoss serialization</title>
-
- <para>The transporter serialization example (found in
- org.jboss.remoting.samples.transporter.serialization package) is very
- similar to the previous basic example, except in this one, the domain
- objects being sent over the wire will NOT be Serializable. This is
- accomplished via the use of JBoss Serialization. This can be useful when
- don't know which domain objects you may be using in remote calls or if
- adding ability for remote calls on legacy code.</para>
-
- <para>To start, there are a few more domain objects: <code>Order</code>,
- <code>OrderProcessor</code>, and <code>OrderProcessorImpl</code>. These
- will use some of the domain objects from the previous example as well,
- such as <code>Customer</code>.</para>
-
- <programlisting>public class <emphasis role="bold">Order</emphasis>
-{
- private int orderId = -1;
- private boolean isProcessed = false;
- private Customer customer = null;
- private List items = null;
-
-
- public int getOrderId()
- {
- return orderId;
- }
-
- public void setOrderId(int orderId)
- {
- this.orderId = orderId;
- }
-
- public boolean isProcessed()
- {
- return isProcessed;
- }
-
- public void setProcessed(boolean processed)
- {
- isProcessed = processed;
- }
-
- public Customer getCustomer()
- {
- return customer;
- }
-
- public void setCustomer(Customer customer)
- {
- this.customer = customer;
- }
-
- public List getItems()
- {
- return items;
- }
-
- public void setItems(List items)
- {
- this.items = items;
- }
-
- public String toString()
- {
- StringBuffer buffer = new StringBuffer();
- buffer.append("\nOrder:\n");
- buffer.append("\nIs processed: " + isProcessed);
- buffer.append("\nOrder id: " + orderId);
- buffer.append(customer.toString());
-
- buffer.append("\nItems ordered:");
- Iterator itr = items.iterator();
- while(itr.hasNext())
- {
- buffer.append("\n" + itr.next().toString());
- }
-
- return buffer.toString();
- }
-}</programlisting>
-
- <programlisting>public class <emphasis role="bold">OrderProcessorImpl</emphasis> implements <emphasis
- role="bold">OrderProcessor</emphasis>
-{
- private CustomerProcessor customerProcessor = null;
-
- public OrderProcessorImpl()
- {
- customerProcessor = new CustomerProcessorImpl();
- }
-
- public Order processOrder(Order order)
- {
- System.out.println("Incoming order to process from customer.\n" + order.getCustomer());
-
- // has this customer been processed?
- if(order.getCustomer().getCustomerId() < 0)
- {
- order.setCustomer(customerProcessor.processCustomer(order.getCustomer()));
- }
-
- List items = order.getItems();
- System.out.println("Items ordered:");
- Iterator itr = items.iterator();
- while(itr.hasNext())
- {
- System.out.println(itr.next());
- }
-
- order.setOrderId(new Random().nextInt(1000));
- order.setProcessed(true);
-
- System.out.println("Order processed. Order id now: " + order.getOrderId());
- return order;
- }
-}</programlisting>
-
- <programlisting>public interface OrderProcessor
-{
- public Order processOrder(Order order);
-}</programlisting>
-
- <para>The <code>OrderProcessorImpl</code> will take orders, via the
- <code>processOrder() </code>method, check that the customer for the
- order has been processed, and if not have the customer processor process
- the new customer. Then will place the order, which means will just set
- the order id and processed attribute to true.</para>
-
- <para>The most important point to this example is that the
- <code>Order</code> class does NOT implement
- <code>java.io.Serializable</code>.</para>
-
- <para>Now onto the <code>Server</code> class. This is just like the
- previous <code>Server</code> class in the basic example with one main
- difference: the <code>locatorURI</code> value.</para>
-
- <programlisting>public class <emphasis role="bold">Server</emphasis>
-{
- private String locatorURI = "socket://localhost:5400/?<emphasis role="bold">serializationtype=jboss</emphasis>";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = TransporterServer.createTransporterServer(locatorURI, new OrderProcessorImpl());
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The addition of <literal>serializationtype=jboss</literal> tells
- the remoting framework to use JBoss Serialization in place of the
- standard java serialization.</para>
-
- <para>On the client side, there is the <code>Client</code> class, just
- as in the previous basic example.</para>
-
- <programlisting>public class <emphasis role="bold">Client</emphasis>
-{
- private String locatorURI = "socket://localhost:5400/?<emphasis role="bold">serializationtype=jboss</emphasis>";
-
- public void makeClientCall() throws Exception
- {
- Order order = createOrder();
-
- OrderProcessor orderProcessor = (OrderProcessor) TransporterClient.createTransporterClient(locatorURI, OrderProcessor.class);
-
- System.out.println("Order to be processed: " + order);
- Order changedOrder = orderProcessor.processOrder(order);
- System.out.println("Order now processed " + changedOrder);
-
- TransporterClient.destroyTransporterClient(orderProcessor);
-
- }
-
- private Order createOrder()
- {
- Order order = new Order();
- Customer customer = createCustomer();
- order.setCustomer(customer);
-
- List items = new ArrayList();
- items.add("Xbox 360");
- items.add("Wireless controller");
- items.add("Ghost Recon 3");
-
- order.setItems(items);
-
- return order;
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanata");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
- client.makeClientCall();
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-}</programlisting>
-
- <para>Again, the biggest difference to note is that have added
- <literal>serializationtype=jboss</literal> to the locator uri.</para>
-
- <para>Note: Running this example requires JDK 1.5.</para>
-
- <para>To run this example, can run the Server and then the Client. Or
- can go to the examples directory and run the ant target 'ant
- run-transporter-serialization-server' and then in another window run the
- ant target 'ant run-transporter-serialization-client'. For
- example:</para>
-
- <programlisting>ant run-transporter-serialization-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-serialization-client</programlisting>
-
- <para>When the server and client are run the output for the
- <code>Client</code> class is:</para>
-
- <programlisting>Order to be processed:
-Order:
-
-Is processed: false
-Order id: -1
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-Items ordered:
-Xbox 360
-Wireless controller
-Ghost Recon 3
-Order now processed
-Order:
-
-Is processed: true
-Order id: 221
-Customer:
-customer id: 861
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-Items ordered:
-Xbox 360
-Wireless controller
-Ghost Recon 3
-</programlisting>
-
- <para>The client output shows the printout of the newly created order
- before calling the <code>OrderProcessor</code> and then the processed
- order afterwards. Noticed that the processed order has its customer's id
- set, its order id set and the processed attribute is set to true.</para>
-
- <para>And the output from the <code>Server</code> is:</para>
-
- <programlisting>Incoming order to process from customer.
-
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-processed customer with new id of 861
-Items ordered:
-Xbox 360
-Wireless controller
-Ghost Recon 3
-Order processed. Order id now: 221
-</programlisting>
-
- <para>The server output shows the printout of the customer before being
- processed and then the order while being processed.</para>
- </section>
-
- <section>
- <title>Transporter sample - clustered</title>
-
- <para>In the previous examples, there has been one and only one target
- POJO to make calls upon. If that target POJO was not available, the
- client call would fail. In the transporter clustered example (found in
- org.jboss.remoting.samples.transporter.clustered package), will show how
- to use the transporter in clustered mode so that if one target POJO
- becomes unavailable, the client call can be seamlessly failed over to
- another available target POJO on the network, regardless of network
- transport type.</para>
-
- <para>This example uses the domain objects from the first, basic
- example, so only need to cover the client and server code. For this
- example, there are three different server classes. The first class is
- the <code>SocketServer</code> class, which is the exact same as the
- <code>Server</code> class in the basic example, except for the call to
- the <code>TransportServer</code>'s <code>createTransportServer()
- </code>method.</para>
-
- <programlisting>public class <emphasis role="bold">SocketServer</emphasis>
-{
- public static String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = <emphasis role="bold">TransporterServer.createTransporterServer(getLocatorURI(), new CustomerProcessorImpl(),
- CustomerProcessor.class.getName(), true)</emphasis>;
- }
-
- protected String getLocatorURI()
- {
- return locatorURI;
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- SocketServer server = new SocketServer();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>Notice that are now calling on the <code>TransportServer</code> to
- create a server with the locator uri and target POJO
- (<code>CustomerProcessorImpl</code>) as before, but have also added the
- interface type of the target POJO (<code>CustomerProcessor</code>) and
- that want clustering turned on (via the last <literal>true</literal>
- parameter).</para>
-
- <para>The interface type of the target POJO is needed because this will
- be used as the subsystem within the remoting server for the target POJO.
- The subsystem value will be what the client uses to determine if
- discovered remoting server is for the target POJO they are looking
- for.</para>
-
- <sidebar>
- <para>The transporter uses the MulticastDetector from JBoss Remoting
- for automatic discovery when in clustered mode. The actual detection
- of remote servers that come online can take up to a few seconds once
- started. There is a JNDI based detector provided within JBoss
- Remoting, but has not been integrated within the transporters
- yet.</para>
- </sidebar>
-
- <para>The second server class is the <code>RMIServer</code> class. The
- <code>RMIServer</code> class extends the <code>SocketServer</code> class
- and uses a different locator uri to specify <literal>rmi</literal> as the
- transport protocol and a different port
- (<literal>5500</literal>).</para>
-
- <programlisting>public class <emphasis role="bold">RMIServer</emphasis> extends <emphasis
- role="bold">SocketServer</emphasis>
-{
- private String localLocatorURI = "<emphasis role="bold">rmi://localhost:5500</emphasis>";
-
- protected String getLocatorURI()
- {
- return localLocatorURI;
- }
-
- public static void main(String[] args)
- {
- SocketServer server = new RMIServer();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The last server class is the <code>HTTPServer</code> class. The
- <code>HTTPServer</code> class also extends the <code>SocketServer</code>
- class and specifies <literal>http</literal> as the transport protocol
- and <literal>5600</literal> as the port to listen for requests
- on.</para>
-
- <programlisting>public class <emphasis role="bold">HTTPServer</emphasis> extends <emphasis
- role="bold">SocketServer</emphasis>
-{
- private String localLocatorURI = "<emphasis role="bold">http://localhost:5600</emphasis>";
-
- protected String getLocatorURI()
- {
- return localLocatorURI;
- }
-
- public static void main(String[] args)
- {
- SocketServer server = new HTTPServer();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>On the client side, there is only the <code>Client</code> class.
- This class is very similar to the one from the basic example. The main
- exceptions are (1) the addition of a <code>TransporterClient</code> call
- to create a transporter client and (2) the fact that it continually
- loops, making calls on its <code>customerProcessor</code> variable to
- process customers. This is done so that when we run the client, we can
- kill the different servers and see that the client continues to loop
- making its calls without any exceptions or errors.</para>
-
- <programlisting>public class <emphasis role="bold">Client</emphasis>
-{
- <emphasis role="bold">private String locatorURI = SocketServer.locatorURI;</emphasis>
-
- private CustomerProcessor customerProcessor = null;
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- System.out.println("Customer to be processed: " + customer);
- <emphasis role="bold">Customer processedCustomer = customerProcessor.processCustomer(customer);</emphasis>
- System.out.println("Customer is now: " + processedCustomer);
-
- //TransporterClient.destroyTransporterClient(customerProcessor);
- }
-
- public void getCustomerProcessor() throws Exception
- {
- customerProcessor = (CustomerProcessor) <emphasis role="bold">TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class, true)</emphasis>;
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanata");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
-<emphasis role="bold"> client.getCustomerProcessor();
- while(true)
- {
- try
- {
- client.makeClientCall();
- Thread.currentThread().sleep(5000);
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-</emphasis> }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-}</programlisting>
-
- <para>The first item of note is that the locator uri from the
- <code>SocketServer</code> class is being used. Technically, this is not
- required as once the clustered <code>TransporterClient</code> is
- started, it will start to discover the remoting servers that exist on
- the network. However, this process can take several seconds to occur, so
- unless it is known that no calls will be made on the remote proxy right
- away, it is best to bootstrap with a known target server.</para>
-
- <para>Can also see that in the <code>main()</code> method, the first
- call on the Client instance is to <code>getCustomerProcessor()</code>.
- This method will call the <code>TransporterClient</code>'s
- <code>createTransporterClient()</code> method and passes the locator uri
- for the target POJO server, the type of POJO's remote proxy, and that
- clustering should be enabled.</para>
-
- <para>After getting the customer processor remote proxy, will
- continually loop making calls using the remote proxy (via the
- <code>processCustomer()</code> method on the
- <code>customerProcessor</code> variable).</para>
-
- <para>To run this example, all the servers need to be started (by
- running the <code>SocketServer</code>, <code>RMIServer</code>, and
- <code>HTTPServer</code> classes). Then run the Client class. This can be
- done via ant targets as well. So for example, could open four console
- windows and enter the ant targets as follows:</para>
-
- <programlisting>ant run-transporter-clustered-socket-server</programlisting>
-
- <programlisting>ant run-transporter-clustered-http-server</programlisting>
-
- <programlisting>ant run-transporter-clustered-rmi-server</programlisting>
-
- <programlisting>ant run-transporter-clustered-client</programlisting>
-
- <para>Once the client starts running, should start to see output logged
- to the <code>SocketServer</code>, since this is the one used to
- bootstrap. This output would look like:</para>
-
- <programlisting>processed customer with new id of 378
-processed customer with new id of 487
-processed customer with new id of 980</programlisting>
-
- <para>Once the <code>SocketServer</code> instance has received a few
- calls, kill this instance. The next time the client makes a call on its
- remote proxy, which happens every five seconds, it should fail over to
- another one of the servers (and will see similar output on that server
- instance). After that server has received a few calls, kill it and
- should see it fail over once again to the last server instance that is
- still running. Then, if kill that server instance, will see a
- CannotConnectException and stack trace similar to the following:</para>
-
- <programlisting><emphasis role="bold">...
-org.jboss.remoting.CannotConnectException</emphasis>: Can not connect http client invoker.
- at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:147)
- at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:56)
- at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:112)
- at org.jboss.remoting.Client.invoke(Client.java:226)
- at org.jboss.remoting.Client.invoke(Client.java:189)
- at org.jboss.remoting.Client.invoke(Client.java:174)
- at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:219)
- at $Proxy0.processCustomer(Unknown Source)
- at org.jboss.remoting.samples.transporter3.client.Client.makeClientCall(Client.java:29)
- at org.jboss.remoting.samples.transporter3.client.Client.main(Client.java:64)
- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
- at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- at java.lang.reflect.Method.invoke(Method.java:585)
- at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
-Caused by: java.net.ConnectException: Connection refused: connect
- at java.net.PlainSocketImpl.socketConnect(Native Method)
- at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
- at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
- at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
- at java.net.Socket.connect(Socket.java:507)
- at java.net.Socket.connect(Socket.java:457)
- at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
- at sun.net.www.http.HttpClient.openServer(HttpClient.java:365)
- at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
- at sun.net.www.http.HttpClient.<init>(HttpClient.java:214)
- at sun.net.www.http.HttpClient.New(HttpClient.java:287)
- at sun.net.www.http.HttpClient.New(HttpClient.java:299)
- at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:792)
- at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:744)
- at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:669)
- at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:836)
- at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:117)
- ... 14 more</programlisting>
-
- <para>since there are no target servers left to make calls on. Notice
- that earlier in the client output there were no errors while was failing
- over to the different servers as they were being killed.</para>
-
- <para>Because the CannotConnectException is being caught within the
- while loop, the client will continue to try calling the remote proxy and
- getting this exception. Now re-run any of the previously killed servers
- and will see that the client will discover that server instance and
- begin to successfully call on that server. The output should look
- something like:</para>
-
- <programlisting>...
- at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:669)
- at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:836)
- at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:117)
- ... 14 more
-
-Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Stree
-city: Atlanata
-state: null
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 633
-first name: Bob
-last name: Smith
-street: 101 Oak Stree
-city: Atlanata
-state: null
-zip: 30249
-
-...</programlisting>
-
- <sidebar>
- <para>As demonstrated in this example, fail over can occur across any
- of the JBoss Remoting transports. Clustered transporters is also
- supported using JBoss Serialization, which was introduced in the
- previous example.</para>
-
- <para>It is important to understand that in the context of
- transporters, clustering means invocation fail over. The JBoss
- Remoting transporters themselves do not handle any form of state
- replication. If this feature were needed, could use JBoss Cache to
- store the target POJO instances so that when their state changed, that
- change would be replicated to the other target POJO instances running
- in other processes.</para>
- </sidebar>
- </section>
-
- <section>
- <title>Transporters sample - multiple</title>
-
- <para>The multiple transporter example (found in
- org.jboss.remoting.samples.transporter.multiple package) shows how can
- have a multiple target pojos exposed via the same TransporterServer. In
- this example, will be two pojos being exposed, CustomerProcessorImpl and
- AccountProcessorImpl. Since the domain objects for this example is
- similar to the others discussed in previous examples, will just focus on
- the server and client code. On the server side, need to create the
- TransporterServer so that will included both of the target pojos.</para>
-
- <programlisting>public class Server
-{
- private String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = TransporterServer.createTransporterServer(locatorURI, new CustomerProcessorImpl(), CustomerProcessor.class.getName());
- server.addHandler(new AccountProcessorImpl(), AccountProcessor.class.getName());
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The TransporterServer is created with the CustomerProcessorImpl as
- the inital target pojo. Now that have a live TransporterServer, can add
- other pojos as targets. This is done using the addHandler() method where
- the target pojo instance is passed and then the interface type to be
- exposed as.</para>
-
- <para>Next have the Client that makes the call to both pojos.</para>
-
- <programlisting>public class Client
-{
- private String locatorURI = "socket://localhost:5400";
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- CustomerProcessor customerProcessor = (CustomerProcessor) TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class);
-
- System.out.println("Customer to be processed: " + customer);
- Customer processedCustomer = customerProcessor.processCustomer(customer);
- System.out.println("Customer is now: " + processedCustomer);
-
- AccountProcessor accountProcessor = (AccountProcessor) TransporterClient.createTransporterClient(locatorURI, AccountProcessor.class);
-
- System.out.println("Asking for a new account to be created for customer.");
- Account account = accountProcessor.createAccount(processedCustomer);
- System.out.println("New account: " + account);
-
- TransporterClient.destroyTransporterClient(customerProcessor);
- TransporterClient.destroyTransporterClient(accountProcessor);
-
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanta");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- org.jboss.remoting.samples.transporter.multiple.client.Client client = new org.jboss.remoting.samples.transporter.multiple.client.Client();
- try
- {
- client.makeClientCall();
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
- }
-
-
-}</programlisting>
-
- <para>Notice that TransporterClients are created for each target pojo
- want to call upon, they just happen to share the same locator uri. These
- are independant instances so need to both be destroyed on their own when
- finished with them.</para>
-
- <para>To run this example, run the Server class and then the Client
- class. This can be done via ant targets
- 'run-transporter-multiple-server' and then
- 'run-transporter-multiple-client'. For example:</para>
-
- <programlisting>ant run-transporter-multiple-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-multiple-client</programlisting>
-
- <para>The output for the server should look similar to:</para>
-
- <programlisting>processed customer with new id of 980
-Created new account with account number: 1 and for customer:
-
-Customer:
-customer id: 980
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249</programlisting>
-
- <para>and the output from the client should look similar to:</para>
-
- <programlisting>Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 980
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-
-Asking for a new account to be created for customer.
-New account: Account - account number: 1
-Customer:
-Customer:
-customer id: 980
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-</programlisting>
- </section>
-
- <section>
- <title>Transporters sample - proxy</title>
-
- <para>The proxy transporter example (found in
- org.jboss.remoting.samples.transporter.proxy package) shows how can have
- a TransporterClient sent over the network and called upon. In this
- example, will have a target pojo, CustomerProcessorImpl which itself
- creates a TransporterClient to another target pojo, Customer, and return
- it as response to a method invocation.</para>
-
- <para>To start, will look at the initial target pojo,
- CustomerProcessorImpl.</para>
-
- <programlisting>public class CustomerProcessorImpl implements CustomerProcessor
-{
- private String locatorURI = "socket://localhost:5401";
-
- /**
- * Takes the customer passed, and if not null and customer id
- * is less than 0, will create a new random id and set it.
- * The customer object returned will be the modified customer
- * object passed.
- *
- * @param customer
- * @return
- */
- public ICustomer processCustomer(Customer customer)
- {
- if (customer != null && customer.getCustomerId() < 0)
- {
- customer.setCustomerId(new Random().nextInt(1000));
- }
-
- ICustomer customerProxy = null;
- try
- {
- TransporterServer server = TransporterServer.createTransporterServer(locatorURI, customer, ICustomer.class.getName());
- customerProxy = (ICustomer) TransporterClient.createTransporterClient(locatorURI, ICustomer.class);
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
-
- System.out.println("processed customer with new id of " + customerProxy.getCustomerId());
- return customerProxy;
- }
-
-}</programlisting>
-
- <para>Notice that the processCustomer() method will take a Customer
- object and set customer id on it. Then it will create a
- TransporterServer for that customer instance and also create a
- TransporterClient for the same instance and return that
- TransporterClient proxy as the return to the processCustomer()
- method.</para>
-
- <para>Next will look at the Customer class. It is a basic data object in
- that is really just stores the customer data.</para>
-
- <programlisting>public class Customer implements Serializable, ICustomer
-{
- private String firstName = null;
- private String lastName = null;
- private Address addr = null;
- private int customerId = -1;
-
- public String getFirstName()
- {
- return firstName;
- }
-
- public void setFirstName(String firstName)
- {
- this.firstName = firstName;
- }
-
- public String getLastName()
- {
- return lastName;
- }
-
- public void setLastName(String lastName)
- {
- this.lastName = lastName;
- }
-
- public Address getAddr()
- {
- return addr;
- }
-
- public void setAddr(Address addr)
- {
- this.addr = addr;
- }
-
- public int getCustomerId()
- {
- return customerId;
- }
-
- public void setCustomerId(int customerId)
- {
- this.customerId = customerId;
- }
-
- public String toString()
- {
- System.out.println("Customer.toString() being called.");
- StringBuffer buffer = new StringBuffer();
- buffer.append("\nCustomer:\n");
- buffer.append("customer id: " + customerId + "\n");
- buffer.append("first name: " + firstName + "\n");
- buffer.append("last name: " + lastName + "\n");
- buffer.append("street: " + addr.getStreet() + "\n");
- buffer.append("city: " + addr.getCity() + "\n");
- buffer.append("state: " + addr.getState() + "\n");
- buffer.append("zip: " + addr.getZip() + "\n");
-
- return buffer.toString();
- }
-
-
-}
-</programlisting>
-
- <para>Notice the toString() method and how it prints out to the standard
- out when being called. This will be important when the sample is run
- later.</para>
-
- <para>Now if look at the Server class, will see is a standard setup like
- have seen in previous samples.</para>
-
- <programlisting>public class Server
-{
- private String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = TransporterServer.createTransporterServer(locatorURI, new CustomerProcessorImpl(), CustomerProcessor.class.getName());
- }
-
- public void stop()
- {
- if (server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>It is creating a TransporterServer for the CustomerProcessImpl
- upon being started and will wait 60 seconds for invocations.</para>
-
- <para>Next is the Client class. </para>
-
- <programlisting>public class Client
-{
- private String locatorURI = "socket://localhost:5400";
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- CustomerProcessor customerProcessor = (CustomerProcessor) TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class);
-
- System.out.println("Customer to be processed: " + customer);
- ICustomer processedCustomer = customerProcessor.processCustomer(customer);
- // processedCustomer returned is actually a proxy to the Customer instnace
- // that lives on the server. So when print it out below, will actually
- // be calling back to the server to get the string (vi toString() call).
- // Notice the output of 'Customer.toString() being called.' on the server side.
- System.out.println("Customer is now: " + processedCustomer);
-
- TransporterClient.destroyTransporterClient(customerProcessor);
-
-
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanta");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
- client.makeClientCall();
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
- }
-
-
-}</programlisting>
-
- <para>The client class looks similar to the other example seen in that
- it creates a TransporterClient for the CustomerProcessor and calls on it
- to process the customer. Will then call on the ICustomer instance
- returned from the processCustomer() method call and call toString() on
- it (in the system out call). </para>
-
- <para>To run this example, run the Server class and then the Client
- class. This can be done via ant targets 'run-transporter-proxy-server'
- and then 'run-transporter-proxy-client'. For example:</para>
-
- <programlisting>ant run-transporter-proxy-server</programlisting>
-
- <para>ant then:</para>
-
- <programlisting>ant run-transporter-proxy-client</programlisting>
-
- <para>The output for the client should look similar to:</para>
-
- <programlisting>Customer.toString() being called.
-Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 418
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-</programlisting>
-
- <para>The first line
- is the print out from calling the Customer's toString() method that was
- created to be passed to the CustomerProcessor's processCustomer()
- method. Then the contents of the Customer object before being processed.
- Then have the print out of the customer after has been processed. Notice
- that when the ICustomer object instance is printed out the second time,
- do not see the 'Customer.toString() being called'. This is because that
- code is no longer being executed in the client vm, but instead is a
- remote call to the customer instance living on the server (remember, the
- processCustomer() method returned a TransporterClient proxy to the
- customer living on the server side).</para>
-
- <para>Now, if look at output from the server will look similar
- to:</para>
-
- <programlisting>processed customer with new id of 418
-Customer.toString() being called.</programlisting>
-
- <para>Notice that the 'Customer.toString() being called.' printed out at
- the end. This is the result of the client's call to print out the
- contents of the customer object returned from the processCustomer()
- method, which actually lives within the server vm.</para>
-
- <para>This example has shown how can pass around TransporterClient
- proxies to target pojos. However, when doing this, is important to
- understand where the code is actually being executed as there are
- consequences to being remote verse local, which need to be
- understood.</para>
- </section>
-
- <section>
- <title>Transporter sample -complex</title>
-
- <para>The complex transporter example (found in
- org.jboss.remoting.samples.transporter.complex package) is based off a
- test case a user, Milt Grinberg, provided (thanks Milt). The example is
- similar to the previous examples, except in this case involves matching
- Doctors and Patients using the ProviderInterface and provides a more
- complex sample in which to demonstrate how to use transporters.</para>
-
- <para>This example requires JDK 1.5 to run, since is using JBoss
- Serialization (and non-serialized data objects). To run this example,
- run the Server class and then the Client class. This can be done via ant
- targets 'run-transporter-complex-server' and then
- 'run-transporter-complex-client' as well. For example:</para>
-
- <programlisting>ant run-transporter-complex-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-complex-client</programlisting>
-
- <para>The output for the client should look similar to:</para>
-
- <programlisting>*** Have a new patient that needs a doctor. The patient is:
-
-Patient:
- Name: Bill Gates
- Ailment - Type: financial, Description: Money coming out the wazoo.
-
-*** Looking for doctor that can help our patient...
-
-*** Found doctor for our patient. Doctor found is:
-Doctor:
- Name: Andy Jones
- Specialty: financial
- Patients:
-
-Patient:
- Name: Larry Ellison
- Ailment - Type: null, Description: null
- Doctor - Name: Andy Jones
-
-Patient:
- Name: Steve Jobs
- Ailment - Type: null, Description: null
- Doctor - Name: Andy Jones
-
-Patient:
- Name: Bill Gates
- Ailment - Type: financial, Description: Money coming out the wazoo.
-
-*** Set doctor as patient's doctor. Patient info is now:
-
-Patient:
- Name: Bill Gates
- Ailment - Type: financial, Description: Money coming out the wazoo.
- Doctor - Name: Andy Jones
-
-*** Have a new patient that we need to find a doctor for (remember, the previous one retired and there are no others)
-*** Could not find doctor for patient. This is an expected exception when there are not doctors available.
-org.jboss.remoting.samples.transporter.complex.NoDoctorAvailableException: No doctor available for ailment 'financial'
- at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:183)
- at org.jboss.remoting.Client.invoke(Client.java:325)
- at org.jboss.remoting.Client.invoke(Client.java:288)
- at org.jboss.remoting.Client.invoke(Client.java:273)
- at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:237)
- at $Proxy0.findDoctor(Unknown Source)
- at org.jboss.remoting.samples.transporter.complex.client.Client.makeClientCall(Client.java:72)
- at org.jboss.remoting.samples.transporter.complex.client.Client.main(Client.java:90)
- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
- at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- at java.lang.reflect.Method.invoke(Method.java:585)
- at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
-</programlisting>
-
- <para>From the output see the creation of a new patient, Bill Gates, and
- the attempt to find a doctor that specializes in his ailment. For Mr.
- Gates, we were able to find a doctor, Andy Jones, and can see that he
- has been added to the list of Dr. Jones' patients. Then we have Dr.
- Jones retire. Then we create a new patient and try to find an available
- doctor for the same ailment. Since Dr. Jones has retired, and there are
- no other doctors that specialize in that particular ailment, an
- exception is thrown. This is as expected.</para>
- </section>
- </section>
-
- <section>
- <title id="section-multiplex-invokers"
- xreflabel="Multiplex invokers">Multiplex invokers</title>
-
- <para>This section illustrates the construction of multiplex invoker
- groups described in the section <xref linkend="section-multiplex-invoker" />. The
- directory</para>
-
- <blockquote>
- <para><code>examples/org/jboss/remoting/samples/multiplex/invoker</code></para>
- </blockquote>
-
- <para>contains a server class,
- <classname>MultiplexInvokerServer</classname>, which is suitable for use
- with any of the client classes described below. It may be run in an IDE or
- from the command line using ant target <code>run-multiplex-server</code>
- from the <code>build.xml</code> file found in the <code>examples</code>
- directory. The server will stay alive, processing invocation requests as
- they are presented, until it has sent two push callbacks to however many
- listeners are registered, at which time it will shut itself down.</para>
-
- <para>The sample clients are as follows. Each sample client
- <emphasis><client></emphasis> may be run in an IDE or by using the
- ant target <code>run-</code><emphasis><client></emphasis> (e.g.,
- <code>run-Client2Server1</code>).</para>
-
- <itemizedlist>
- <listitem>
- <para><classname>Client2Server1</classname>: A
- <classname>MultiplexClientInvoker</classname> starts according to
- client rule 2, after which a
- <classname>MultiplexServerInvoker</classname> is started according to
- server rule 1. Note that the <classname>Client</classname> and
- <classname>Connector</classname> are passed matching
- <emphasis>clientMultiplexId</emphasis> and
- <emphasis>serverMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Client2Server2</classname>: A
- <classname>MultiplexClientInvoker</classname> starts according to
- client rule 2, after which a
- <classname>MultiplexServerInvoker</classname> is started according to
- server rule 2. Note that no <emphasis>clientMultiplexId</emphasis> is
- passed to the <classname>Client</classname> and no
- <emphasis>serverMultiplexId</emphasis> parameter is passed to the
- <classname>Connector</classname> in this example.</para>
- </listitem>
-
- <listitem>
- <para><classname>Client3Server1</classname>: A
- <classname>MultiplexClientInvoker</classname> is created, and, lacking
- binding information, finds itself governed by client rule 3.
- Subsequently, a <classname>MultiplexServerInvoker</classname> is
- started according to server rule 1, providing the binding information
- which allows the <classname>MultiplexClientInvoker</classname> to
- start. Note that the <classname>Client</classname> and
- <classname>Connector</classname> are passed matching
- <emphasis>clientMultiplexId</emphasis> and
- <emphasis>serverMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server2Client1</classname>: A
- <classname>MultiplexServerInvoker</classname> starts according to
- server rule 2, after which a
- <classname>MultiplexClientInvoker</classname> is started according to
- client rule 1. Note that the <classname>Connector</classname> and
- <classname>Client</classname> are passed matching
- <emphasis>serverMultiplexId</emphasis> and
- <emphasis>clientMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server2Client2</classname>: A
- <classname>MultiplexServerInvoker</classname> starts according to
- server rule 2, after which a
- <classname>MultiplexClientInvoker</classname> is started according to
- client rule 2. Note that no <emphasis>serverMultiplexId</emphasis> is
- passed to the <classname>Connector</classname> and no
- <emphasis>clientMultiplexId</emphasis> parameter is passed to the
- <classname>Client</classname> in this example.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server3Client1</classname>: A
- <classname>MultiplexServerInvoker</classname> is created, and, lacking
- connect information, finds itself governed by server rule 3.
- Subsequently, a <classname>MultiplexClientInvoker</classname> is
- started according to client rule 1, providing the connect information
- which allows the <classname>MultiplexServerInvoker</classname> to
- start. Note that the <classname>Connector</classname> and
- <classname>Client</classname> are passed matching
- <emphasis>serverMultiplexId</emphasis> and
- <emphasis>clientMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
- </itemizedlist>
-
- <para>For variety, the examples in which the client invoker starts first
- use the configuration <classname>Map</classname> to pass invoker group
- parameters, and the examples in which the server invoker starts first pass
- parameters in the <classname>InvokerLocator</classname>.</para>
- </section>
-</chapter>
\ No newline at end of file
+ <para>When boiled down, transporters take a plain old java object (POJO)
+ and expose a remote proxy to it via JBoss Remoting. Dynamic proxies and
+ reflection are used to make the typed method calls on that target POJO.
+ Since JBoss Remoting is used, can select from a number of different
+ network transports (i.e. rmi, http, socket, multiplex, etc.), including
+ support for SSL. Even clustering features can be included. See the
+ transporter samples in the next chapter for detailed examples of how to
+ set up use of a transporter.</para>
+ </chapter>
\ No newline at end of file
Modified: remoting2/tags/2.4.0-GA/docs/guide/en/chap12.xml
===================================================================
--- remoting2/tags/2.4.0-GA/docs/guide/en/chap12.xml 2008-06-08 23:33:38 UTC (rev 4275)
+++ remoting2/tags/2.4.0-GA/docs/guide/en/chap12.xml 2008-06-08 23:43:55 UTC (rev 4276)
@@ -1,17 +1,23 @@
<chapter>
- <title>Compatibility and versioning</title>
+ <title>Client programming model</title>
- <para>As of JBossRemoting 2.0.0 versioning has been added to guarantee
- compatibility between different versions. This is accomplished by changing
- serialization formats for certain classes and by using wire versioning. By
- wire versioning, mean that the version used by a client and server will be
- sent on the wire so that the other side will be able to adjust
- accordingly. This will be automatic for JBossRemoting 2.0.0 and later
- versions. However, since versioning was not introduced until the 2.0.0
- release, if need to have a 1.4.x version of remoting communicate to a
- later version, will need to set a system property on the 2.0.0 version so
- that knows to use the older wire protocol version. The system property to
- set is 'jboss.remoting.pre_2_0_compatible' and should be set to true.
- There are a few minor features that will not be fully compatible between
- 1.4.x release and 2.0.0, which are listed in the release notes.</para>
+ <para>The approach taken for the programming model on the client side is
+ one based on a session based model. This means that it is expected that
+ once a Client is created for a particular target server, it will be used
+ exclusively to make calls on that server. This expectation dictates some
+ of the behavior of the remoting client.</para>
+
+ <para>For example, if create a Client on the client side to make server
+ invocations, including adding callback listeners, will have to use that
+ same instance of Client to remove the callback listeners. This is because
+ the Client creates a unique session id that it passes within the calls to
+ the server. This id is used as part of the key for registering callback
+ listeners on the server. If create a new Client instance and attempt to
+ remove the callback listeners, a new session id will be passed to the
+ server invoker, who will not recognize the callback listener to be
+ removed.</para>
+
+ <para>See test case
+ <code>org.jboss.test.remoting.callback.push.MultipleCallbackServersTestCase</code>
+ .</para>
</chapter>
\ No newline at end of file
Modified: remoting2/tags/2.4.0-GA/docs/guide/en/chap15.xml
===================================================================
--- remoting2/tags/2.4.0-GA/docs/guide/en/chap15.xml 2008-06-08 23:33:38 UTC (rev 4275)
+++ remoting2/tags/2.4.0-GA/docs/guide/en/chap15.xml 2008-06-08 23:43:55 UTC (rev 4276)
@@ -1,22 +1,16 @@
<chapter>
- <title>Future plans</title>
+ <title>Known issues</title>
- <para>Full road map for JBossRemoting can be found at <!--<link linkend="???">
- http://jira.jboss.com/jira/browse/JBREM?report=com.atlassian.jira.plugin....
- </link>--> <ulink
- url="http://jira.jboss.com/jira/browse/JBREM?report=com.atlassian.jira.plugin....">
- http://jira.jboss.com/jira/browse/JBREM?report=com.atlassian.jira.plugin....
- </ulink>.</para>
-
- <para>If you have questions, comments, bugs, fixes, contributions, or
- flames, please post them to the JBoss Remoting users forum <!--<link linkend="???">http://www.jboss.com/index.html?module=bb&op=viewforum&f=222</link>-->
+ <para>All of the known issues and road map can be found on our bug
+ tracking system, Jira, at <!--<link linkend="???">http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031</link>-->
+ <ulink
+ url="http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031">
+ http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031 </ulink>
+ (require member plus registration, which is free). If you find more,
+ please post them to Jira. If you have questions post them to the JBoss
+ Remoting users forum <!--<link linkend="???">http://www.jboss.com/index.html?module=bb&op=viewforum&f=222</link>-->
(<ulink
url="http://www.jboss.com/index.html?module=bb&op=viewforum&f=222">
http://www.jboss.com/index.html?module=bb&op=viewforum&f=222
- </ulink>). You can also find more information about JBoss Remoting on our
- <!--<link linkend="???">http://www.jboss.org/wiki/Wiki.jsp?page=Remoting</link>-->
- wiki (<ulink url="http://www.jboss.org/wiki/Wiki.jsp?page=Remoting">
- http://www.jboss.org/wiki/Wiki.jsp?page=Remoting </ulink> ). The wiki will
- usually contain the latest updates to doc and features that did not make
- into previous release.</para>
+ </ulink>).</para>
</chapter>
\ No newline at end of file
Modified: remoting2/tags/2.4.0-GA/docs/guide/en/chap7.xml
===================================================================
--- remoting2/tags/2.4.0-GA/docs/guide/en/chap7.xml 2008-06-08 23:33:38 UTC (rev 4275)
+++ remoting2/tags/2.4.0-GA/docs/guide/en/chap7.xml 2008-06-08 23:43:55 UTC (rev 4276)
@@ -1,44 +1,121 @@
- <chapter>
- <title>Serialization</title>
+<chapter>
+ <title>Sending streams</title>
- <para>Serialization - how it works within remoting: In general, remoting
- will rely on a factory to provide the serialization implementation, or
- <code>org.jboss.remoting.serialization.SerializationManager</code>, to be
- used when doing object serialization. This factory is
- <code>org.jboss.remoting.serialization.SerializationStreamFactory</code>
- and is a (as defined by its javadoc):</para>
+ <para>Remoting supports the sending of InputStreams. It is important to
+ note that this feature DOES NOT copy the stream data directly from the
+ client to the server, but is a true on demand stream. Although this is
+ obviously slower than reading from a stream on the server that has been
+ copied locally, it does allow for true streaming on the server. It also
+ allows for better memory control by the user (versus the framework trying
+ to copy a 3 Gig file into memory and getting out of memory errors).</para>
- <literallayout>factory is for defining the Object stream implemenations to be used along with creating those implemenations for use.
-The main function will be to return instance of ObjectOutput and ObjectInput. By default, the implementations will be
-java.io.ObjectOutputStream and java.io.ObjectInputStream.
-</literallayout>
+ <para>Use of this new feature is simple. From the client side, there is a
+ method in org.jboss.remoting.Client with the signature:</para>
- <para>Currently there are only two different types of serialization
- implementations; 'java' and 'jboss'. The 'java' type uses
- <code>org.jboss.remoting.serialization.impl.java.JavaSerializationManager</code>
- as the SerializationManager implementation and is backed by standard Java
- serialization provide by the JVM, which is the default. The 'jboss' type
- uses
- <code>org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager</code>
- as the SerializationManager implementation and is backed by JBoss
- Serialization.</para>
+ <programlisting>public Object invoke(InputStream inputStream, Object param) throws Throwable
+ </programlisting>
- <para>JBoss Serialization is a new project under development to provide a
- more performant implementation of object serialization. It complies with
- java serialization standard with three exceptions:</para>
+ <para>So from the client side, would just call invoke as done in the past,
+ and pass the InputStream and the payload as the parameters. An example of
+ the code from the client side would be (this is taken directly from
+ org.jboss.test.remoting.stream.StreamingTestClient):</para>
- <para>- SerialUID not needed</para>
+ <programlisting>
+ String param = "foobar";
+ File testFile = new File(fileURL.getFile());
+ ...
+ Object ret = remotingClient.invoke(fileInput, param);
+ </programlisting>
- <para>- java.io.Serializable is not required</para>
+ <para>From the server side, will need to implement
+ <code>org.jboss.remoting.stream.StreamInvocationHandler</code> instead of
+ <code>org.jboss.remoting.ServerInvocationHandler</code> .
+ StreamInvocationHandler extends ServerInvocationHandler, with the addition
+ of one new method:</para>
- <para>- different protocol</para>
+ <programlisting>public Object handleStream(InputStream stream, Object param)</programlisting>
- <para>JBoss Serialization requires JDK 1.5</para>
+ <para>The stream passed to this method can be called on just as any
+ regular local stream. Under the covers, the InputStream passed is really
+ proxy to the real input stream that exists in the client's VM. Subsequent
+ calls to the passed stream will actually be converted to calls on the real
+ stream on the client via this proxy. If the client makes an invocation on
+ the server passing an InputStream as the parameter and the server handler
+ does not implement StreamInvocationhandler, an exception will be thrown to
+ the client caller.</para>
- <para></para>
+ <para>If want to have more control over the stream server being created to
+ send the stream data back to the caller, instead of letting remoting
+ create it internally, can do this by creating a Connector to act as stream
+ server and pass it when making Client invocation.</para>
- <para>It is possible to override the default SerializationManger
- implementation to be used by setting the system property 'SERIALIZATION'
- to the fully qualified name of the class to use (which will need to
- provide a void constructor).</para>
+ <programlisting>public Object invoke(InputStream inputStream, Object param, Connector streamConnector) throws Throwable</programlisting>
+
+ <para>Note, the Connector passed must already have been started (else an
+ exception will be thrown). The stream handler will then be added to the
+ connector with the subystem 'stream'. The Connector passed will NOT be
+ stopped when the stream is closed by the server's stream proxy (which
+ happens automatically when remoting creates the stream server
+ internally).</para>
+
+ <para>Can also call <methodname>invoke()</methodname> method on client and
+ pass the invoker locator
+ would like to use and allow remoting to create the stream server using the
+ specified locator.</para>
+
+ <programlisting>public Object invoke(InputStream inputStream, Object param, InvokerLocator streamServerLocator) throws Throwable </programlisting>
+
+ <para>In this case, the Connector created internally by remoting will be
+ stopped when the stream is closed by the server's stream proxy.</para>
+
+ <para>It is VERY IMPORTANT that the StreamInvocationHandler implementation
+ close the InputStream when it finishes reading, as will close the real
+ stream that lives within the client VM.</para>
+
+ <section>
+ <title>Configuration</title>
+
+ <para>By default, the stream server which runs within the client JVM
+ uses the following values for its locator uri:</para>
+
+ <para>transport - socket</para>
+
+ <para>host - tries to first get local host name and if that fails, the
+ local ip (if that fails, localhost).</para>
+
+ <para>port - 5405</para>
+
+ <para>Currently, the only way to override these settings is to set the
+ following system properties (either via JVM arguments or via
+ <code>System.setProperty()</code> method):</para>
+
+ <para>remoting.stream.transport - sets the transport type (rmi, http,
+ socket, etc.)</para>
+
+ <para>remoting.stream.host - host name or ip address to use</para>
+
+ <para>remoting.stream.port - the port to listen on</para>
+
+ <para>These properties are important because currently the only way for
+ a target server to get the stream data from the stream server (running
+ within the client JVM) is to have the server invoker make the invocation
+ on a new connection back to the client (see issues below).</para>
+ </section>
+
+ <section>
+ <title>Issues</title>
+
+ <para>This is a first pass at the implementation and needs some work in
+ regards to optimizations and configuration. In particular, there is a
+ remoting server that is started to service requests from the stream
+ proxy on the target server for data from the original stream. This
+ raises an issue with the current transports, since the client will have
+ to accept calls for the original stream on a different socket. This may
+ be difficult when control over the client's environment (including
+ firewalls) may not be available. A bi-directional transport, called
+ multiplex, is being introduced as of 1.4.0 release which will allow
+ calls from the server to go over the same socket connection established
+ by the client to the server (JBREM-91). This will make communications
+ back to client much simpler from this standpoint.</para>
+ </section>
</chapter>
\ No newline at end of file
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4275 - remoting2/tags.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-08 19:33:38 -0400 (Sun, 08 Jun 2008)
New Revision: 4275
Added:
remoting2/tags/2.4.0-GA/
Log:
Copied: remoting2/tags/2.4.0-GA (from rev 4274, remoting2/branches/2.x)
16 years, 5 months
- 1
- 0
JBoss Remoting SVN: r4274 - remoting2/tags.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-06-08 19:29:55 -0400 (Sun, 08 Jun 2008)
New Revision: 4274
Removed:
remoting2/tags/2.4.0-GA/
Log:
16 years, 5 months
- 1
- 0