- Apr 08, 2013
-
-
Ceki Gulcu authored
-
Carl Harris authored
Just a first draft. Please edit and/or pare down as appropriate.
-
Ceki Gulcu authored
-
Ceki Gulcu authored
-
Ceki Gulcu authored
-
Ceki Gulcu authored
-
Ceki Gulcu authored
-
Ceki Gulcu authored
-
Carl Harris authored
-
Carl Harris authored
components
-
Carl Harris authored
-
Carl Harris authored
This ensures that no queuing occurs when the number of threads is less than or equal to the maximumPoolSize. Also added constants for all of the default values, and changed the defaults for maximumPoolSize and keepAliveTime.
-
Carl Harris authored
-
Ceki Gulcu authored
-
Ceki Gulcu authored
-
Ceki Gulcu authored
-
- Apr 05, 2013
-
-
Carl Harris authored
The ExecutorService in the context has a very limited thread pool configuration, and using it as is breaks the existing socket-based components that rely on concurrent execution.
-
- Apr 04, 2013
-
-
Carl Harris authored
This test was broken when the InstrumentedServerSocketBase was modified to allow assertion testing for the context's executor service.
-
Carl Harris authored
n ServerSocket.stop, we must not shut down the executor service if it belongs to the context. We only shut down an executor that we created specifically for the server.
-
Carl Harris authored
If the server has no thread pool configuration, the context's executor service is now used by default.
-
Carl Harris authored
If a subclass provides a custom executor, we want to shut it down, but if the context's executor is used, we must not shut it down. The revised test covers both cases.
-
Carl Harris authored
The SocketRemote component doesn't want/need to allow the user to provide a thread pool configuration, anyway, so we might as well use the executor service provided by the context instead of creating our own.
-
Carl Harris authored
In ServerSocketAppenderBase.stop, we must not shut down the executor service if it is the context's executorService. We only shut down an executor that we created specifically for this appender.
-
Carl Harris authored
If the appender does not have a thread pool configuration, we now use the context's ExecutorService instead of creating a new one based on the default ThreadPoolConfiguration.
-
Carl Harris authored
-
Carl Harris authored
When testing the exception reported by SocketConnectorBase after a connection failure, the test now uses lock and associated condition to avoid synchronization issues.
-
Carl Harris authored
The context injected by logback into SocketServer is subsequently injected into RemoteAppenderServerRunner. The runner simply casts it to LoggerContext before injecting it into the client object.
-
Ceki Gulcu authored
updated documentation for simplified scala-less build, increased timeout in AppenderAttachableImplLockTest
-
Carl Harris authored
work in progress on documentation of SocketRemote/ServerSocketAppender
-
Carl Harris authored
Committing before moving to a clone of qos-ch/logback instead of my fork.
-
Carl Harris authored
removed some assertions that were not critical
-
Carl Harris authored
The test was system timing sensitive due to testing some assertions on fields without proper synchronization. The assertions themselves were not especially critical, and adding the synchronization would have added significant complexity, so the assertions were removed.
-
Carl Harris authored
reduce system timing sensitivity in SocketConnectorBaseTest
-
Carl Harris authored
LOGBACK-826: work in progress on documentation
-
Carl Harris authored
Now using a larger delay tolerance and additional Thread.join calls to give the connector thread time to exit before testing assertions that it did exit properly.
-
Carl Harris authored
-
Carl Harris authored
Other example configurations using layout remain and need the same treatment.
-
Carl Harris authored
-
Carl Harris authored
-
Carl Harris authored
changed SocketRemote address property to host
-