Meeting Minutes:
Agenda:
1.) Expiring of Keys proposal / changes and potential impacts.
Jeanfrancois has implemented the proposed changes which would move the
expiring of keys out of the Controller.doSelect() into the default tcp
SelectorHandler.postSelect(). No one on the dev mailing list has
disagreed with the doing so. One of the concerns mentioned by Charlie
was the potential of breaking existing Grizzly based applications.
However, that impact should apply only to those applications which are
using the Controller, not using the default tcp SelectorHandler and
expecting keys to be expired. No one in today's meeting knows of anyone
who has this type of configuration.
2.) tcpNoDelay & Socket options being set on both Connector (client) and
SelectorHandler (server).
Jeanfrancois has implemented this change and it has been integrated into
the trunk. This will ensure that SocketChannels initiated from a
default Grizzly client (Connector) will have the same Socket options
enabled / disabled as that of a default Grizzly accepted server
connection (SelectorHandler).
3.) Ext release: 1.5.3 or 1.6.0
Jeanfrancois would like to discuss whether to use a 1.5.3 or 1.6.0
Grizzly version number for the next official release. Decision and
further discussion will be delayed until having additional input from
Ken and others in the community. Adoption, maintenance and consistency
with the proposed release numbering scheme are the main issues. If we
go to 1.6.0 as the proposed release numbering suggests, migration to
1.6.0 may not occur as quickly as to 1.5.3. There's also more
maintenance associated with a 1.6.0 next release since we'll have to
maintain 1.5.2.
4.) Other project changes / updates.
Nothing noteworthy.
5.) Grizzly integration into GlassFish ORB, (questions / issues).
Harsha described some of the issues he has identified in his effort to
integrate Grizzly with GlassFish ORB. Charlie suggested that much of
the existing GlassFish CORBA implementation that gets invoked upon it
receiving an OP_READ event should be integrated into a Grizzly
ProtocolFilter. GlassFish ORB's MessageParser should get migrated to a
Grizzly ProtocolParser. The ProtocolFilter should call the
ProtocolParser and when a message is parsed, a GlassFish ORB's
CorbaMessageMediator should be created and then put on the GlassFish
ORB's thread pool work queue. In order to create a
CorbaMessageMediator, a CorbaConnection will be needed. The key piece
to a CorbaConnection is the underlying SocketChannel which can be gotten
inside the ProtocolFilter. The CorbaConnection is what allows the
'dispatch' side of the GlassFish ORB to write responses to the inbound
message. This should be major pieces of what's needed to integrate the
OP_READ part of GlassFish ORB to using Grizzly.
charlie ...
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>