javaee / grizzly

Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Grizzly NIO framework has been designed to help developers to take advantage of the Java™ NIO API.

⚠️This project is now part of the EE4J initiative. This repository has been archived as all activities are now happening in the corresponding Eclipse repository. See here for the overall EE4J transition status.

---

Grizzly NIO

Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Grizzly NIO framework has been designed to help developers to take advantage of the Java™ NIO API. Grizzly’s goal is to help developers to build scalable and robust servers using NIO as well as offering extended framework components: Web Framework (HTTP/S), WebSocket, Comet, and more!

Getting Started

Grizzly currently has several lines of development in the following branches:

• 2.3.x : This is the sustaining branch for 2.3. (latest release is 2.3.33)
• master : This is the sustaining branch for the most recent major release of Grizzly. (latest release is 2.4.2)
• 3.0.x : This is our upcoming 3.0 release. Fair warning; it's not backwards compatible with previous releases.

There are other branches for older releases of Grizzly that we don't actively maintain at this time, but we keep them for the history.

Prerequisites

We have different JDK requirements depending on the branch in use:

• Oracle JDK 1.8 for master and 3.0.x branches.
• Oracle JDK 1.7 for 2.3.x.

Apache Maven 3.3.9 or later in order to build and run the tests.

Installing

See https://javaee.github.io/grizzly/dependencies.html for the maven coordinates of the 2.3.x release artifacts.

If building in your local environment:

mvn clean install

Running the tests

mvn clean install

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

License

This project is licensed under the CDDLw/CPE - see the LICENSE.txt file for details.

grizzly's Issues

useless function call in udpselectorhandler

in UDPSelectorHandler::preSelect function

datagramChannel.configureBlocking(false); is used twice

Environment

Operating System: All
Platform: All

Remove the asymmetry in channel event handling in Grizzly

Grizzly uses two different approaches in hanlding nio selector's OP_READ,
OP_WRITE, OP_CONNECT... events. One approach is by having a callback handlers on
the client side and the other one is using filters on the serverside.

I had compared this design with a typical AWT/SWING event handling. Using
callback handling seems like a very efficient of handling selector events. That
means, we will have a callback to be invoked upon occurring of particular
selector event. This also helps Grizzly developer to just define what needs to
be done upon a particular event and then, handle the rest of undelying taks of
register/deregister of the channel with the selector to Grizzly. The only
difference from AWT/SWING is, here in Grizzly we should be able to process
multiple events at the same time in multiple threads.

Environment

Operating System: All
Platform: Sun

Build for examples does not follow Maven 2 standards

The examples build does not follow Maven 2 best practices.

Since GF uses Maven 2 so should the examples.

Environment

Operating System: All
Platform: Macintosh

Affected Versions

[1.9.22]

can not configure Logger in Grizzly to use log4j

We use log4j in our application to do the logging. And we have some
standard format defined for the log file. What is the best way to
pipe the Grizzly logs to log4j other than changing the source code of
Grizzly?

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Patch for OutputWriter.write()

From the community, fyaoxy "at" gmail.com, a patch contribution for
com.sun.grizzly.util.OutputWriter.java

Index:
F:/svn/grizzly/modules/grizzly/src/main/java/com/sun/grizzly/util/OutputWriter.java

===================================================================

—
F:/svn/grizzly/modules/grizzly/src/main/java/com/sun/grizzly/util/OutputWriter.java
(revision 394)

+++
F:/svn/grizzly/modules/grizzly/src/main/java/com/sun/grizzly/util/OutputWriter.java
(working copy)

@@ -86,14 +86,13 @@

try {
while ( bb.hasRemaining() ) {
int len = socketChannel.write(bb);

• attempts++;

• if (len < 0) { - throw new EOFException(); - }

• bytesProduced += len;

• if (len == 0) {

  • if (len>0) { + attempts = 0; + bytesProduced += len; + }

  else {

  • //handle write count = 0;NOTE write() return result >=0, no <0
    exist.
  • attempts++;

  if ( writeSelector == null ){
  writeSelector = SelectorFactory.getSelector();
  if ( writeSelector == null)

  { @@ -111,8 +110,7 @@ }

  else

  { attempts--; }

• } else { - attempts = 0; + //handle write count = 0 end; }

  }
  } finally {

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

typo in comment

UDPSelectorHandler.java

This class represent a UPD implementation

Environment

Operating System: All
Platform: All

need a way to pass the exceptions generated in filters to the Grizzly user

I'm filing this issue to track the earlier discussion around exception handling
around read or any other similar filters in Grizzly. Here is detail description
of the problem, in the email archive :

https://grizzly.dev.java.net/servlets/ReadMsg?list=dev&msgNo=680

The scenario is, when an exception happens (say, a connection error, or a parser
error while parsing..) the developer of Grizzly would like to take some
definitive action in the application. This requirement applies to both server
and client side.

Its a good idea to have a callback mechanism (or event handling /listeners) to
register for a specific exceptions and then pass them to the registered objects
for action upon their occurrence.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]

typo in controller.java

By default, the Grizzly Framework bundle default implementation for TCP and UPD
transport.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Grizzly v161: TCPConnectorHandler breaks while compiling with 161 version

This bug is another compatibility issue. And is minor, but is valid as far as
public APIs are concerned. The method

TCPConnectorHandler.java: public void finishConnect(SelectionKey key){}
is changed from its type. The old version does not throw an exception.

But the new one throws throws IOException.

My application which was running earlier on prior version of Grizzly, needed to
be modified to compile and run against v1.6.1.

This change came from:
r490, line 425 | r508, line 429

• Finish handling the OP_CONNECT interest ops.
• @param key - a SelectionKey
  */
  < public void finishConnect(SelectionKey key){

  public void finishConnect(SelectionKey key) throws IOException{

thanks..

Environment

Operating System: All
Platform: Sun

typo in javadoc/controller.java

life cycle of a SelectionKey. Operations like cancelling,

double ll in canceling

Environment

Operating System: All
Platform: All

split the start method of Controller

The Controller start method can be split into many segments.

One idea is, to create all defaults in a method called init()
and the selector handler for loop in a different method
and much more..

this way, the controller.start() method looks simpler and easy to understand for
the develoer who is using Grizzly.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]

BufferOverflowException in SocketChannelOutputBuffer

public void realWriteBytes(byte cbuf[], int off, int len)
throws IOException {
if (len > 0) {
if (len > outputByteBuffer.remaining())

{ ByteBuffer tmp = ByteBuffer.allocate( outputByteBuffer.capacity() * 2 + len); outputByteBuffer.flip(); tmp.put(outputByteBuffer); outputByteBuffer = tmp; }

outputByteBuffer.put(cbuf, off, len);
}
}

if position + len is bigger than capacity * 2, outputByteBuffer overflows.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Unable to add library to the classpath

The current jruby jars doesn't allow the addition of extra library (like mySql
driver). This need to be fixed.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

ConnectorHandlerPool and its implementor - names need correction

This is about:
interface ConnectorHandlerPool.java
and it's implementor DefaultConnectorHandlerPool.java

First of all the word "Pool" gives an impression to the user of this framework
that, this class is POOL of ConnectorHanlders which is definetely not the case
here. All that this class and it's interface do is to provide impelemenation for
aquring a connection and release a connection (I guees from a pool or linked
concurrent queue).

This name toooo confusing.

Here are some suggestions:
for the interface: ConnectionPoolManager.java
ConnectionPoolManagerImpl.java

Or ConnectionPoolEvent.java
ConnectionPoolEventHandler.java

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]

DefaultProtocolChainInstanceHandler - needs name correction

The class DefaultProtocolChainInstanceHandler really does not do what it name
says. The funtionality of the class is, to have a Concurrent Linked Queue of
protocol chains. There should a name to reflect this functionality.

Here are some suggestions:
ProtocolChainCache.java
ProtocolChainPool.java
ProtocolChainsQueue.java

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]

Grizzly ARP broken

I grabbed the HTTP part of grizzly today and pulled out what I had done
previously against the 1.0 version to port to 1.5-SNAPSHOT. Where before I had:

public static void main(String[] args) throws IOException,
InstantiationException
{
SelectorThread sel = new SelectorThread();
sel.setPort(8002);

sel.setAdapter(new MyAdapter());

final AsyncHandler handler = new DefaultAsyncHandler();
handler.addAsyncFilter(new AsyncFilter()
{
public boolean doFilter(final AsyncExecutor executor)
{
final AsyncTask asyncTask = executor.getAsyncTask();
final AsyncHandler asyncHandler = executor.getAsyncHandler();

final DefaultProcessorTask processorTask =
(DefaultProcessorTask) executor.getAsyncTask().getProcessorTask();
processorTask.getRequest().setAttribute(CALLBACK_KEY, new
Runnable() {
public void run()

{ asyncHandler.handle(asyncTask); }

});
processorTask.invokeAdapter();
return false;
}
});
sel.setAsyncHandler(handler);
sel.setEnableAsyncExecution(true);
sel.setDisplayConfiguration(true);
sel.initEndpoint();
sel.startEndpoint();
}

and an adaptor:

class MyAdapter implements Adapter
{
static byte[] CONTENT;

{ CONTENT = ByteChunk.convertToBytes("hello world!\n"); }

private static final ScheduledExecutorService exec =
Executors.newScheduledThreadPool(2);

public void service(final Request req, final Response res) throws Exception
{
System.out.println("got request");
exec.schedule(new Callable() {
public Void call() throws Exception

{ res.setStatus(200); byte[] bytes = CONTENT; ByteChunk chunk = new ByteChunk(); res.setContentLength(bytes.length); res.setContentType("text/plain"); chunk.append(bytes, 0, bytes.length); res.doWrite(chunk); System.out.println("sending resposne!"); Async.commit(req); return null; }

}, 10, TimeUnit.SECONDS);
}

public void afterService(Request req, Response res) throws Exception

{ req.action( ActionCode.ACTION_POST_REQUEST , null); }

public void fireAdapterEvent(String type, Object data)
{
}
}

Which would correctly respond in 10 seconds, now it responds with nothing
immediately, and 10 seconds later attempts to respond but doesn't actually do
anything (also logging no error).

Any guidelines on how to do ARP with the new code?

Environment

Operating System: All
Platform: All

Affected Versions

[memcached-1.0]

redundant code

SelectorHandlerRunner.java::run

while (controller.state == State.STARTED) {
– cut –
// State changed inside the loop
if (controller.state != State.STARTED)

{ break; }

– cut –

no need to check controller.state twice, its checked every time at top of loop.

Environment

Operating System: All
Platform: All

How to integrate FindBugs w/NetBeans 6.0 document

A written tutorial on how to integrate the FindBugs plug-in for
NetBeans IDE and run it from within NetBeans IDE 6, (Note: the FindBugs
plug-in may not operational in NetBeans IDE 6).

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

typo in controller.java comment

// Selector.select() invokation.

invocation

Environment

Operating System: All
Platform: All

Missing Junit tests cometd

There are no JUnit tests in the cometd package.

Environment

Operating System: All
Platform: Macintosh

Affected Versions

[1.9.22]

KeepAliveStats doesn't register when connections are closed.

The result of SelectorThread.getKeepAliveStats().getCountConnections() never decreases when
connections are closed, so instead of returning the current number of open connections, it returns the
total number of connections over the full lifetime of the application.

From the implementation, it seems we are missing the logic to decrease the count:

public boolean trap(SelectionKey key){
if ( maxKeepAliveRequests == -1) return true;
Integer count = keepAliveCounts.get(key);
if ( count == null ){
count = 0;
if (keepAliveStats != null)

{ keepAliveStats.incrementCountConnections(); }

}
if ((count++) > maxKeepAliveRequests){
if (keepAliveStats != null)

{ keepAliveStats.incrementCountRefusals(); }

return false;
}
keepAliveCounts.put(key, count);
if (keepAliveStats != null)

{ keepAliveStats.incrementCountHits(); }

return true;
}
/**

• Stop monitoring keep-alive request count for the given connection.
  */
  public void untrap(SelectionKey key) { if ( maxKeepAliveRequests == -1) return; keepAliveCounts.remove(key); }

Inside the untrap(..), we must decrease the count. Can you file a bug here:

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

more typos in controller.java

• Stop the Controller by cancelling all the registered keys

canceling

/**

• Return an instance of a ConnectorHandler based on the
• Protocol requeted.
  */

requested

/**

• Method waits until all initialized SelectorHandlers will
• not get stoped
  */

stopped

Environment

Operating System: All
Platform: All

SSL connection is getting closed during handshake phase

One of http module unit test fails with exception:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

End chunk not send correctly

Hello,

In the grizzly http, the "0\r\n\r\n" ending for a HTTP message is not send in a
seperate chunk but appended to the last data chunk.

Here is a more visual explenation:

grizzly chunked HTTP response

chunk 1 <<
HTTP/1.1 200 OK
Transform-Encoding: chunked
.. other headers

1234
hello world
0

end chunk 1 <<

---

other servers chunked HTTP response

chunk 1 <<
HTTP/1.1 200 OK
Transform-Encoding: chunked
.. other headers

1234
hello world

end chunk 1 <<

chunk 2 <<
HTTP/1.1 200 OK
Transform-Encoding: chunked
.. other headers

0

end chunk 2 <<

---

Other HTTP servers send the "0\r\n\r\n" in a seperate (as the last) chunk.
As far as I got from the HTTP spec it is supposed to be like that.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Remove dependencies on com.sun.org.apache classes

Right now modules http & utils have dependencies on
com.sun.org.apache.commons.logging|modeler. This was a requirement when Grizzly
was bundled in GlassFish, but now it should be removed and we should instead
uses package from Apache itself.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

tcpNoDelay needs to be explicitly assigned on the Connector

Currently the TCPSelectorHandler, by default sets the Socket's tcpNoDelay to
false when a new SocketChannel is accepted. This also needs to be set on the
TCPConnectorHandler when a client initiated connection is established.

Separate from the TCPConnectorHandler not explicitly assigning tcpNoDelay,
there's a potential bug in TCPSelectorHandler.configureChannel(). It assumes
the default for a java.net.Socket's tcpNoDelay will also be false by default.
If the underlying JDK changes this default from false to true, AND Grizzly wants
the tcpNoDelay to be false, it will not get set to false. Here's that segment
of code from TCPSelectorHandler.configureChannel():
if(tcpNoDelay)
socket.setTcpNoDelay(tcpNoDelay);
This probably ought to be changed to:
if (socket.getTcpNoDelay() && tcpNoDelay)
socket.setTcpNoDelay(tcpNoDelay);
Or, simply:
socket.setTcpNoDelay(tcpNoDelay);

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Grizzly's connection caching tutorial

A written tutorial on how to use Grizzly's connection caching
including a run-able example.

Environment

Operating System: All
Platform: All

grizzly-jruby doesn't work on JRuby 1.1 and Rails 2.0

Test platform:
JRuby 1.1RC1
Rails 2.0.2

To reproduce:

1. rails grizzly-jruby-test
2. go to grizzly-jruby-test directory and rake rails:freeze:gems
3. java -jar grizzly-jruby-1.7-snapshot.jar .

Error message:
2008. 1. 10 ???? 12:00:15 com.sun.grizzly.standalone.StaticResourcesAdapter
????: New Servicing page from:
/Volumes/FLASHBACK/workspace/grizzly-jruby-test/public
Exception in thread "pool-1-thread-1" 2008. 1. 10 ???? 12:00:23
com.sun.grizzly.standalone.StaticResourcesAdapter
????: New Servicing page from:
/Volumes/FLASHBACK/workspace/grizzly-jruby-test/public
/Volumes/FLASHBACK/workspace/grizzly-jruby-test/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:499:in
require': no implicit conversion from nil to integer (TypeError) from ./config/../vendor/rails/railties/lib/initializer.rb:155:in require_frameworks'
from ./config/../vendor/rails/railties/lib/initializer.rb:88:in each' from ./config/../vendor/rails/railties/lib/initializer.rb:156:in require_frameworks'
from ./config/../vendor/rails/railties/lib/initializer.rb:88:in process' from ./config/../vendor/rails/railties/lib/initializer.rb:49:in send'
from ./config/../vendor/rails/railties/lib/initializer.rb:49:in `run'
from ./config/environment.rb:58
from javasupport:46
...internal jruby stack elided...
from org.jruby.Ruby.loadScript(Ruby.java:1185)
from org.jruby.runtime.load.ExternalScript.load(ExternalScript.java:53)
from org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:307)
from org.jruby.runtime.load.LoadService.require(LoadService.java:333)
from
com.sun.grizzly.jruby.RubyObjectPool.loadRubyLibraries(RubyObjectPool.java:168)
from com.sun.grizzly.jruby.RubyObjectPool$1.run(RubyObjectPool.java:135)
from
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
from
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
from java.lang.Thread.run(Thread.java:637)

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

TCPSelectorHandler needs a new constructor

Ar present, TCPSelectoHandler().. forces the user to create a socket first and
then supply it to the connect(..) method.
Instead, its much easier and simple to just accept "host" and numeric 'port'
from user then constuct the InetSocketAddress internally in the consturctor..

For example,

TCPSelectoHandler tsh = new TCPSelectoHandler(host, port) //string and int
tsh.connect(); //to connect to given host and port

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]

Controller.java javadoc typo

• Internal countdown counter of SelectorHandlers, which stoped

stopped

Environment

Operating System: All
Platform: All

Grizzly ignores the selector handlers added to Controller if the controller is already running

Grizzly v1.6.1/0 onwards:
Grizzly ignores the TCP selection handlers added if the controller is
already started. In the old versions this is not a problem.

Here is a TENTATIVE fix: In Controller.java:

public void addSelectorHandler(SelectorHandler selectorHandler){
if (selectorHandlers == null)

{ selectorHandlers = new ConcurrentLinkedQueue(); }

selectorHandlers.add(selectorHandler);

if (isStarted())

{ Runnable selectorRunner = new SelectorHandlerRunner(this, selectorHandler); new Thread(selectorRunner).start(); }

}

Environment

Operating System: All
Platform: Sun

Update center is not visible in NetBeans 6.0 Beta1

The catalog https://sqe.dev.java.net/updatecenters/sqe/catalog.xml should use
DTD 2.5 to be supported in NetBeans 6.0 Beta 1.
The current catalog uses version 3.0 which causes that users of NetBeans 6.0
Beta1 can see empty list while connected to this update center. So that plugins
cannot be installed.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Make a clear difference between client and server for TCPSelectorHandler()

At present, Grizzly frameworks TCPSelectorHandler(..) construct has a boolean
as an argument to tell if that particualr transport handler is going to be on
the client side or not. This is not clear to user when he reads someone code.

My suggestion would be to make it really distinguishable part on the
TransportHandler.
For example, you could say, TCPServerSideHandle() and TCPCliendSideHandler()
or TCPSelectorHandler.setRole(Role.AsServer);
TCPSelectorHandler.setRole(Role.AsClient);

thanks...

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]

No JUnit tests

There are no junit tests in the comet package

Environment

Operating System: All
Platform: Macintosh

Affected Versions

[1.9.22]

Expiring of SelectionKeys should not be mandatory

There are set of applications which do not require the expiring of
SelectionKeys, (i.e. require keep alive). See Controller.doSelect(), which does:

iterator = readyKeys.iterator();
long currentTime = System.currentTimeMillis();
while (iterator.hasNext() && selectorHandler.isOpen())

{ key = iterator.next(); selectionKeyHandler.expire(key,currentTime); }

A possible solution to this issue is to move the above logic into the
TCPSelectorHandler.postSelect() method, which is currently empty.

Then, create a new class that implements SelectorHandler interface which is
called NonExpiringTCPSelectorHandler which would take on all the methods of the
TCPSelectorHandler with the exception of the TCPSelectorHandler.postSelect().
postSelect() should be empty for the NonExpiringTCPSelectorHandler. Then, the
TCPSelectorHandler should extend NonExpiringTCPSelectorHandler and have one
method in it. The override of postSelect() method which contains the expiring
of keys logic above.

For those applications which do not need to expire keys, they would configure
the Controller to use the NonExpiringTCPSelectorHandler. This could be done at
the Grizzly configuration setup time by doing something like:

Controller sel = new Controller();
SelectorHandler selectorHandler = new NonExpiringSelectorHandler();
// set any additional items on the SelectorHandler
sel.setSelectorHandler(selectorHandler);
sel.setProtocolChainInstanceHandler(new DefaultProtocolChainInstanceHandler(){
public ProtocolChain poll() {
ProtocolChain protocolChain = protocolChains.poll();
if (protocolChain == null)

{ protocolChain = new DefaultProtocolChain(); protocolChain.addFilter(new ReadFilter()); protocolChain.addFilter(new HTTPParserFilter()); }

return protocolChain;
}
});

This proposed resolution would also not break the SSLSelectorHandler or
UDPSelectorHandler as they are currently implemented. However, if there are SSL
or UDP applications out there which do not need to "expire keys", then a similar
resolution will need to be implemented as well since both SSLSelectorHandler
and UDPSelectorHandler extend TCPSelectorHandler.

Other applications which need expiring of keys would continue to work as they do
today. No changes would be required since the TCPSelectorHandler is the default
SelectorHandler and its functionality would not change.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

How to integrate FindBugs w/NetBeans document

A written tutorial on how to integrate the FindBugs plug-in for
NetBeans IDE and run it from within NetBeans IDE 5.5 / 5.5.1.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Grizzly framework workspace directory structure related

Here is the list that I've for the workspace dir. structure.

1. Remove directory "main" if it's not needed.
2. Push all interfaces to a different directory under com/sun/grizzly/spi?
3. Push all default implementations to a dir called defaults under
com/sun/grizzly/defaults?

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]

typo in controller.java doc

instead consist of sharing the ProtocolFilter amongs ProtocolChain:

among

Environment

Operating System: All
Platform: All

possible wrong javadoc in Controller.java

ConcurrentLinkedQueue getSelectorHandlers()
Return the first SelectorHandler

instead of return first, should be most likely returns all

Environment

Operating System: All
Platform: All

Add SSL Support to http module

The current http module doesn't support SSL. This is a regression from 1.0.x

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

typo in UDPSelectorHandler.java

/**

• A token decribing the protocol supported by an implementation of this
• interface
  */

describing

Environment

Operating System: All
Platform: All

Tutorial on getting source code and building with Meven IDE

This is a place holder for a tutorial contribution to show how to get and build
the project grizzly source code using Meven IDE. Adam Dutson has volunteered
to create this tutorial. Thanks Adam!

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

ConnectorHandlerPool and its implementor - names need correction

This is about:
interface ConnectorHandlerPool.java
and it's implementor DefaultConnectorHandlerPool.java

First of all the word "Pool" gives an impression to the user of this framework
that, this class is POOL of ConnectorHanlders which is definetely not the case
here. All that this class and it's interface do is to provide impelemenation for
aquring a connection and release a connection (I guees from a pool or linked
concurrent queue).

This name toooo confusing. ConnectionPoolManager.java

Here are some suggestions:
for the interface:

Environment

Operating System: All
Platform: Sun

Affected Versions

[2.0.0]

Need multiplexing of underlying channel(s) in Grizzly

At present in Grizzly, we can not do multiplexing on a given channel. Take a
scenario where a single channel is used by multiple clients (one-2-many) to send
and receive information. Grizzly assumes that, only one client can send (write)
data at any given time. Well, practically, it's not true. For example, in Corba,
multiple threads /clients can send data to the server side at the same time, on
the same channel. One way to handle this problem is, to implement locking at
the protocol level. The otherway is to take care of this in transport layer
itself and making it transperent to the Grizzly developer. (who uses Grizzly to
develop his/her applications)

Environment

Operating System: All
Platform: Sun

OutputWriter can't handle multiple writers

The OutputWriter class is intended to wait up to 1 minute (default wait time)
for output space to be available to complete writing the data. In an HTTP mode
(or for similar protocols), that works just fine.

For protocols (like SIP) where multiple threads are writing to the same socket,
buffer contention will cause OutputWriter to report an error prematurely. Say
there are 10 threads writing on the socket that fills up; all 10 will get a
selector and enter the select() call. When the socket buffer empties, all 10
will get notified that they can write data, and all will attempt to write their
data – but while the socket is still draining, it's likely that only 1 will
succeed and the remaining will write 0 bytes again. If this process is repeated
twice, the remaining sockets will give up (based on the attempts value in
OutputWriter) and close the socket. This entire process takes only a few
milliseconds, since during that time there will be two successful writes.

The async queueing model should take this into account, or we should develop a
selector-per-socket model such that only one thread can wake up from the select
at a time.

Environment

Operating System: All
Platform: All

grizzly-jruby doesn't support extra gem packages outside jruby-complete.jar

On JRuby 1.1(RC1) and Rails 2.0(.2),
suppose "hpricot" gem is installed within JRUBY_HOME and
environment.rb has
require "hpricot", then the following error comes up:
Exception in thread "pool-1-thread-1" ./config/environment.rb:15: no such file
to load – hpricot (LoadError)
from :1
...internal jruby stack elided...
Copying "hpricot" gem into vendor/gems doesn't work either.

Environment

Operating System: All
Platform: All

SSL support in http module not ported from 1.0

Needs to enable SSL with http module in 1.5 using the framework classes from 1.5.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Multiple SelectorThread not supported with the WebServer in 1.5

The feature needs to be re-implemented using the framework classes from 1.5
because right now configuring the value has no effect. Should be simple based on
Alexey's work.

Environment

Operating System: All
Platform: All

Affected Versions

[1.9.22]

Possibility of getting into a read() operation even when the channel is not ready

Please note the below references in the following description of the problem.

Ref A: Controller.java : doSelect(..) method
Ref B: Context.java : call(..) method
Ref C: TCPSelectorHandler.java : onReadInterest(final..)
Ref D: TCPSelectorHandler.java : onWriteInterest(final..)

Also note that, unless otherwise one overrides any of Grizzly's classes.., by
default, Grizzly uses filters on the Serverside (say for reading) and Callback
handlers on the client side. (Ref.issue 41).

Now take the case of a serverside reading..
During the time of doSelect() as in (A), say the given channel is ready to
read, so, the program controll goes to (C) from line:342(A) and since there is
no callback handler (since it's serverside) it returns true (which delegate to
worker thread boolean).. in (A) line:363.. Now, Grizzly invokes the protocol
chain. This is fine and no problem here. Say the next cycle of doSelect(A)
(since there is while loop) the event is not OP_READ but it's OP_WRITE.. the
program control goes "happily" to (D) and returns true from there. Which means
to delegate work to workere thread that's line:363(A) Now, Grizzly goes and
invokes the protocol chain and hence the read filter at the WRONG time.

Now, if there is protocol filter that's tied to a protocol parser for reading
(supporting) a sepecific protocol, it will definetely thinks that, there is data
that's going to come for parsing, since Grizzly invoked Read filter at the wrong
time. But since, no data is expected, zero bytes are read and given to the
parser to parse. If the parser is very smart, it thinks that, this current read
op has Zero fresh bytes, that's because, this is an unsuccessful read() and so,
it tells the parser to expect more data as the channel is ready to read.
Actually, the channel is NOT ready to read at that point of time.

What all this tells is, (from Ref(A)), Of OP_READ, OP_WRITE, filters get
executed all the time.

That's all I noted.

Have fun!
-Harsha

Environment

Operating System: All
Platform: Sun

remove instance from all the class and interface names

Please consider this for future, if this is not possible now.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.9.22]