cb4e7982b1
jetty-9 SslConnection fill does not try to send close handshake
2012-09-24 13:10:18 +10:00
9e7fcf4fee
jetty-9: Fixed SslBytesServerTest, and added factory methods to relevant classes.
2012-09-21 16:47:01 +02:00
e04494da64
jetty-9 fixed test onOpen
2012-09-21 18:00:46 +10:00
68ee346b8a
jetty-9 combined the Container and AggregateLifeCycle into ContainerLifeCycle
2012-09-21 11:45:51 +10:00
b9ceb8703d
Merge branch 'jetty-9' into jetty-9-open-close
2012-09-21 08:36:22 +10:00
857498b115
Upgrading to junit-dep-4.10.jar (banning junit.jar)
2012-09-20 11:52:59 -07:00
37a7e5977d
Merged branch 'jetty-9' into jetty-9-open-close.
2012-09-20 18:46:16 +02:00
40382bad3a
jetty-9 - Removed references to JUnit 3.x.
2012-09-20 18:23:02 +02:00
0d2627b6e9
jetty-9 improved onOpen onclose handling
2012-09-20 11:05:20 +10:00
851de69d9d
jetty-9 - Third take at open/close refactoring.
2012-09-19 18:04:15 +02:00
44b3bb067c
jetty-9 - Second take at open/close refactoring.
2012-09-19 13:37:47 +02:00
f257f4b2bb
jetty-9 - First take at open/close refactoring.
2012-09-19 13:37:47 +02:00
0915b2b0ab
jetty-9 - Refactored code that was counting the number of reentrant invocations into a common utility class, ForkInvoker.
2012-09-17 14:39:13 +02:00
4ea5734ab1
jetty-9 - Avoiding StackOverflowErrors when processing changes.
2012-09-17 11:46:26 +02:00
4f1a2990de
jetty-9 - Always making SslConnection dispatch completion callbacks to avoid StackOverflowErrors.
2012-09-17 11:46:26 +02:00
129583679a
jetty-9 javadoc improvements and renamed SelectChannelConnector to ServerConnector
2012-09-17 17:37:56 +10:00
4ffe66f899
jetty-9 - HTTP client: better cleanup at stop.
2012-09-14 23:30:21 +02:00
88cbfed7e0
jetty-9 - Made SelectorManager.connection[Opened|Closed]() concrete, since they are overridden only by SelectChannelConnector.
2012-09-14 23:30:21 +02:00
cf3f12297f
jetty-9 - Cosmetics.
2012-09-14 23:30:21 +02:00
8c9f097666
jetty-9 - Throwing EofException when trying to flush after output shutdown.
...
When the output is shutdown, field _cannotAcceptMoreAppDataToFlush is set to true,
indicating that no more flush() calls are accepted.
However, a further call to flush() was reading _cannotAcceptMoreAppDataToFlush and
just returning false, leaving writes in pending state but without chance to be completed.
Now, if we detect _cannotAcceptMoreAppDataToFlush==true in flush(), we check
whether the output was shutdown; if it is the case, we throw an EofException to signal
to the application that it cannot write because the connection is already closed.
2012-09-14 15:20:10 +02:00
655a313fdf
jetty-9 - Improved logging.
2012-09-14 15:09:22 +02:00
22ba57b8d2
jetty-9 refactored onOpen and onClose
2012-09-14 17:38:47 +10:00
b264f20dc9
jetty-9 - Removed the write of an empty buffer from onOpen().
...
SslConnection should remain as passive as possible, with the next connection driving the activity.
If client connections need to drive the SSL handshake with an empty write, they should do it, and
not SslConnection.
2012-09-14 00:38:25 +02:00
24cbb6385b
jetty-9 - Just returning in case we want to fail an already failed write flusher.
2012-09-14 00:38:25 +02:00
12470a2715
Introduce SocketBased, and squelching logging on tests
2012-09-13 08:51:45 -07:00
c709981aa5
jetty-9 finished refactor for oneconnector and configuration pluggability
2012-09-13 10:00:44 +10:00
a41b6e32ac
Merge branch 'jetty-9-configuration' into jetty-9
...
Conflicts:
jetty-io/src/main/java/org/eclipse/jetty/io/ssl/SslConnection.java
2012-09-13 08:22:06 +10:00
b3e8f91026
jetty-9 flush returns boolean to say completely flushed or not
2012-09-13 08:11:05 +10:00
79caf45604
Merge branch 'jetty-9' into jetty-9-configuration
...
Conflicts:
jetty-io/src/main/java/org/eclipse/jetty/io/ssl/SslConnection.java
2012-09-12 23:11:12 +10:00
427a01855c
jetty-9 WriteFlusher handlers buffering endpoints
2012-09-12 23:06:19 +10:00
550f0d28f6
attempting to address the SCEPSslTest.testWriteBlocked() failures
2012-09-10 15:15:31 -07:00
26f5ffc459
jetty-9 improve SslConnection toString
2012-09-11 08:04:33 +10:00
73ebe89019
jetty-9 refactored configuration
2012-09-10 20:26:14 +10:00
a15d71932f
jetty-9 protection from double onFillable calls
2012-09-09 08:31:31 +10:00
2bb425d0b2
jetty-9 improved buffer recycling
2012-09-09 07:42:03 +10:00
236df8e94b
Jetty9 - Fixed compilation issues.
2012-09-06 09:37:11 +02:00
7231c82b69
Merged branch 'jetty-9' into jetty-9-client.
2012-09-06 08:41:48 +02:00
2715f64441
Jetty9 - Fourth take at HTTP client implementation.
2012-09-05 13:33:38 +02:00
b18ab0e76a
Jetty9 - First take at HTTP client implementation.
2012-09-04 19:20:29 +02:00
c3776764f4
jetty-9 ConcurrentScheduler refinements
2012-09-03 15:24:36 +10:00
83dbca6553
jetty-9 reworked the schedulers
2012-08-31 13:22:58 +10:00
8c6ad12088
jetty-9 fixed ArrayByteBufferPool and added test
2012-08-31 08:05:09 +10:00
8fbe6c59d5
jetty-9 merge
2012-08-29 17:27:26 +02:00
d84eee0b46
Jetty9 - Reverted AbstractConnector to use MappedByteBufferPool, as ArrayByteBufferPool is leaking buffers.
2012-08-28 18:14:22 +02:00
7a2b53d987
Jetty9 - Dispatching the onConnect(Session) callback in a different thread.
...
This is needed for two reasons: the first is that onOpen() is called from the selector thread
and onConnect() may perform I/O (such as sending a SETTINGS frame), and second
because onOpen() may be called when NPN upgrades the connection.
In the latter case, SslConnection is busy with the SSL handshake (for example is filling)
and calling onConnect() triggers a write, that ends up in the SslConnection that sees that
it is still in the SSL handshake and needs to fill, resulting in a reentrant fill, which is not
supported correctly by SslConnection.
Dispatching to a new thread makes the call safe, since SslConnection is properly synchronized.
2012-08-28 15:20:14 +02:00
2339da7cc0
Jetty9 - Marked tests as @Slow.
2012-08-28 13:04:18 +02:00
5aa3702606
Jetty9 - Better logging.
2012-08-28 11:56:37 +02:00
6601b65162
Jetty9 - Made the test more reliable and marked it as slow.
2012-08-28 11:56:22 +02:00
7a1faf3c08
Jetty9 - Start counting for idleness when we register read interest.
...
Otherwise it was possible that the endPoint was created, upon creation
it started counting for idleness, after a while read interested was set
and the endPoint idle timed out before having the chance to read.
2012-08-28 11:55:01 +02:00
a935c26764
Jetty9 - Fixed typo.
2012-08-27 16:32:01 +02:00
Greg Wilkins
Simone Bordet
Joakim Erdfelt
Thomas Becker