You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by no...@apache.org on 2006/11/10 22:00:37 UTC
svn commit: r473471 -
/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Author: noel
Date: Fri Nov 10 13:00:36 2006
New Revision: 473471
URL: http://svn.apache.org/viewvc?view=rev&rev=473471
Log:
JAMES-684. A somewhat more appropriate version of the test, but may be exposing a portability concern for this test.
Modified:
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Modified: james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java?view=diff&rev=473471&r1=473470&r2=473471
==============================================================================
--- james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java (original)
+++ james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java Fri Nov 10 13:00:36 2006
@@ -1019,39 +1019,95 @@
}
/*
- REMOVED UNTIL FIXED. This test assumes behavior that is wrong.
What we want to see is that for a given connection limit and a
given backlog, that connection limit requests are handled, and
that up to the backlog number of connections are queued. More
- connections than that would eventually error out (unless space
- opened up in front of them during the TCP/IP handshake).
+ connections than that should error out until space opens up in
+ the queue.
+
+ For example:
+
+ # telnet localhost <m_smtpListenPort>
+ Trying 127.0.0.1...
+ telnet: Unable to connect to remote host: Connection refused
+
+ is the immediate response if the backlog is full.
+ */
public void testConnectionLimitExceeded() throws Exception {
- m_testConfiguration.setConnectionLimit(1); // allow no more than one connection at a time
+ final int acceptLimit = 1;
+ final int backlog = 1;
+
+ m_testConfiguration.setConnectionLimit(acceptLimit); // allow no more than <acceptLimit> connection(s) in the service
+ m_testConfiguration.setConnectionBacklog(backlog); // allow <backlog> additional connection(s) in the queue
finishSetUp(m_testConfiguration);
- SMTPClient smtpProtocol1 = new SMTPClient();
- SMTPClient smtpProtocol2 = new SMTPClient();
- smtpProtocol1.connect("127.0.0.1", m_smtpListenerPort);
- assertTrue("first connection taken", smtpProtocol1.isConnected());
+
+ final SMTPClient[] client = new SMTPClient[acceptLimit];
+ for (int i = 0; i < client.length; i++) {
+ client[i] = new SMTPClient(); // should connect to worker
+ try {
+ client[i].connect("127.0.0.1", m_smtpListenerPort);
+ } catch (Exception _) {
+ }
+ assertTrue("client #" + (i+1) + " established", client[i].isConnected());
+ }
+
+ // Cannot use SMTPClient. It appears that even though the
+ // client's socket is established, since the client won't be
+ // able to connect to the protocol handler, the connect call
+ // hangs.
+
+ // not sure why this isn't just backlog, but empirically, I'm
+ // getting a few more connections than I should. I've tested
+ // 2 and 4 (as well as 0, of course), and the result is
+ // consistent on Ubuntu 2.6.12-10-amd64-k8-smp: <3 means that
+ // the connection that should fail succeeds and >3 means that
+ // a connection intended to backlog fails.
+ final Socket connection[] = new Socket[backlog+3];
+
+ final java.net.SocketAddress server = new java.net.InetSocketAddress("localhost", m_smtpListenerPort);
+
+ for (int i = 0; i < connection.length; i++) {
+ connection[i] = new Socket();
+ try {
+ connection[i].connect(server, 1000);
+ } catch (Exception _) {
+ }
+ assertTrue("connection #" + (i+1) + " established", connection[i].isConnected());
+ }
try {
- smtpProtocol2.connect("127.0.0.1", m_smtpListenerPort);
- fail("second connection not taken1");
- } catch (Exception e) {
+ final Socket shouldFail = new Socket();
+ shouldFail.connect(server, 1000);
+ fail("connection # " + (client.length + connection.length + 1) + " did not fail.");
+ } catch (Exception _) {
}
-
- // disconnect the first
- smtpProtocol1.quit();
- smtpProtocol1.disconnect();
-
+
+ client[0].quit();
+ client[0].disconnect();
+
Thread.sleep(100);
- // now the second should be able to connect
- smtpProtocol2.connect("127.0.0.1", m_smtpListenerPort);
- assertTrue(smtpProtocol2.isConnected());
+ // now should be able to connect (backlog)
+ try {
+ final Socket shouldWork = new Socket();
+ shouldWork.connect(server, 1000);
+ assertTrue("Additional connection established after close.", shouldWork.isConnected());
+ shouldWork.close();
+ } catch (Exception e) {
+ fail("Could not establish additional connection after close." + e.getMessage());
+ }
+
+ // close the pending connections first, so that the server doesn't see them
+ for (int i = 0; i < connection.length; i++) connection[i].close();
+
+ // close the remaining clients
+ for (int i = 1; i < client.length; i++) {
+ client[i].quit();
+ client[i].disconnect();
+ }
}
- */
// RemoteDelivery tests.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473471 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/11/06, Noel J. Bergman <no...@devtech.com> wrote:
> Bernd Fondermann wrote:
>
> > MacOS:
>
> > Testcase: testConnectionLimitExceeded took 1.006 sec
> > FAILED
> > connection #3 established
>
> Sounds as if MacOS X doesn't have that so-called "grace" margin. Please try
> the revised code and let me know if that works. It should. :-)
It does :-)
Thanks for taking the time!
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r473471 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bernd Fondermann wrote:
> MacOS:
> Testcase: testConnectionLimitExceeded took 1.006 sec
> FAILED
> connection #3 established
Sounds as if MacOS X doesn't have that so-called "grace" margin. Please try
the revised code and let me know if that works. It should. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473471 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Bernd Fondermann <be...@googlemail.com>.
On 11/10/06, Noel J. Bergman <no...@devtech.com> wrote:
> + // not sure why this isn't just backlog, but empirically, I'm
> + // getting a few more connections than I should. I've tested
> + // 2 and 4 (as well as 0, of course), and the result is
> + // consistent on Ubuntu 2.6.12-10-amd64-k8-smp: <3 means that
> + // the connection that should fail succeeds and >3 means that
> + // a connection intended to backlog fails.
> + final Socket connection[] = new Socket[backlog+3];
>
> Would people please try this unit test on their systems, and let me know what results they are seeing? I have tested this code on Ubuntu 2.6.12-10-amd64-k8-smp and CentOS 2.6.9-42.0.3.EL with the same results.
Sure. MacOS:
Testcase: testConnectionLimitExceeded took 1.006 sec
FAILED
connection #3 established
junit.framework.AssertionFailedError: connection #3 established
at org.apache.james.smtpserver.SMTPServerTest.testConnectionLimitExceeded(SMTPServerTest.java:1077)
(Sorry, just running the test, no time trying to figure out why this
happens... Hope this helps anyway)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473471 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Stefano Bagnara <ap...@bago.org>.
>> - Windows XP Pro SP2 Italian (i386)
>> - FreeBSD 6.1 (i386)
>> - Fedora FC5 (2.6.17-1.2174_FC5) (i686/athlon)
>> they passes
>
> This was with the latest, self-adjusting, test code --- the same code that worked for Bernd on Mac OS X --- yes?
Right!
r468907 (current trunk)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r473471 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
> > Would people please try this unit test on their systems,
> > and let me know what results they are seeing?
> - Windows XP Pro SP2 Italian (i386)
> - FreeBSD 6.1 (i386)
> - Fedora FC5 (2.6.17-1.2174_FC5) (i686/athlon)
> they passes
This was with the latest, self-adjusting, test code --- the same code that worked for Bernd on Mac OS X --- yes?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r473471 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Would people please try this unit test on their systems, and let me know what results they are seeing?
Ran the tests under:
- Windows XP Pro SP2 Italian (i386)
- FreeBSD 6.1 (i386)
- Fedora FC5 (2.6.17-1.2174_FC5) (i686/athlon)
and they passes.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r473471 - /james/server/trunk/src/test/org/apache/james/smtpserver/SMTPServerTest.java
Posted by "Noel J. Bergman" <no...@devtech.com>.
+ // not sure why this isn't just backlog, but empirically, I'm
+ // getting a few more connections than I should. I've tested
+ // 2 and 4 (as well as 0, of course), and the result is
+ // consistent on Ubuntu 2.6.12-10-amd64-k8-smp: <3 means that
+ // the connection that should fail succeeds and >3 means that
+ // a connection intended to backlog fails.
+ final Socket connection[] = new Socket[backlog+3];
Would people please try this unit test on their systems, and let me know what results they are seeing? I have tested this code on Ubuntu 2.6.12-10-amd64-k8-smp and CentOS 2.6.9-42.0.3.EL with the same results.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org