FYI, the current 3.2 snapshot is less stable than usual because of a
significant number of low-level threading/socket and session
refactoring. While snapshots should not be used in production, it's
even more true with the current version.
Work in progress on the snapshot:
1. Threading/sockets - because the new comet and hmtp/xmpp services
have different socket/threading requirements from straight http, we're
reworking the low-level socket handling to better support all the new
models. With the changes, we should be able to handle very-large
numbers of mostly-inactive sockets, e.g. with 10,000 xmpp clients.
2. Dynamic clustering. We're working on allowing for dynamic
clustering support, so you can add or remove dynamic servers as your
load changes, e.g. for a Amazon-style compute cloud. There will
always be a core set of static servers, but an allowed pool of dynamic
servers as well.
The configuration model for the dynamic clustering uses JMX to add/
remove a dynamic server to the cluster, and then a command-line option
to start the dynamic server itself (for the watchdog.)
3. Clustered session updates. Mostly these involve adding support for
the dynamic servers. The current clustering model is built around
static servers, and needs to be changed. We'll probably require
backups to be stored on the static servers (so reconfiguration doesn't
cause chaos), while the session owner can be one of the dynamic servers.
Related session changes include better reliability/performance on
startup. Startup is a tricky time since the server needs to
synchronize its state with the rest of the cluster. The previous
implementation essentially froze the new server while that
synchronization occurred, which could cause problems when there was a
large amount of data. WIth the updates, the new server can start
immediately and asynchronously update with the cluster.
4. Quercus bug fixes - steady progress on PHP compatibility and
Quercus bug fixes (see bug list/changelog for details).
5. JSF 2.0 draft implementation - the snapshot is including features
from the new JSF 2.0 draft specification as we implement them.
6. bam/hmtp/xmpp work and refactoring. We're continuing to clean up
and refactor the bam/hmtp API. The main changes in 3.2 are splitting
out the Bam interfaces themself from Hmtp and reducing the complexity
of the Bam API.
The purpose of BAM (brokered agent messaging) is to serve as a
foundation for the next-generation of interactive web applications,
which uses instant messaging to replace HTTP polling for small-scale
notifications (e.g. twitter or our sudoku game or IM or asynct rss/
7. misc bugs :)
resin-interest mailing list