Archived
This forum has been archived. Please start a new discussion on GitHub.
Upcoming features in Ice 3.3
mes
California
We've been asked what to expect from the upcoming release of Ice. Below is a tentative list of the notable new features and changes:
- Background I/O
Before this release, invoking an Ice operation on a TCP or SSL connection could potentially block, even when using AMI and oneway invocations. Users developing GUI and other applications that could not tolerate delays employed a variety of strategies for avoiding blocking invocations, none of which were particularly convenient. In this release, Ice guarantees that the following types of invocations never block: oneway AMI, twoway AMI, and batch oneway. Regular (non-AMI) oneway and twoway invocations continue to have the same semantics as in prior releases, namely that blocking can occur when establishing a connection or sending a message (see this faq for more information).
Background I/O is also used on the server side, such as when sending responses to clients. Servers that handle invocations using AMD no longer risk network delays when the operation completes. Furthermore, this feature enhances reliability by preventing malicious clients from blocking threads in the server thread pool. - Scalability improvements in Glacier2
The Glacier2 router takes full advantage of the new background I/O semantics to improve its scalability. Before this release, Glacier2 always used the thread-per-connection concurrency model (despite its greater resource consumption compared to the thread pool concurrency model) because it was more resilient to malicious clients. However, background I/O allows Glacier2 to use the thread pool concurrency model by default, providing the same safety guarantees as in prior releases while using a fixed number of threads. - Highly-available IceStorm
Ice 3.3 introduces Highly-available (HA) IceStorm, featuring master-slave replication with automatic failover in the event of a master failing. HA IceStorm is typically deployed using IceGrid replication groups. Applications require no changes to take advantage of the HA capabilities. - Freeze Transactional Evictor
This release adds a new kind of Freeze Evictor in which all write operations are automatically enclosed in a Freeze transaction. This new Evictor gives applications write-ordering guarantees, allows developers to enclose several operations in the same transaction (when using collocated invocations), and helps ensure data consistency when recovering from a crash. - Ice Admin object
An Ice server can now easily publish a multi-facet Ice Admin object that provides administrative access to the server, such as the ability to remotely shutdown the server's communicator or retrieve the communicator's properties. This mechanism is extensible: any server can add facets to the Admin object and provide custom administrative access. For example, IceBox adds a new facet that allows clients to remotely start or stop individual IceBox services. Integration with IceGrid provides secure access to these Ice Admin objects and facets through IceGrid. - Dynamic network interfaces
Ice server endpoints that are configured to listen on all local interfaces now listen on INADDR_ANY/0.0.0.0 rather than listening separately on each of the interfaces that were found during server startup. This means that if a new interface becomes available while the server is running, Ice will be able to receive and process requests using that interface. - UDP multicast support
UDP endpoints now support multicast addresses. One possible use for this new feature is as a server location mechanism. During bootstrapping a client could send a multicast message asking for all available servers to respond. The client would then select from one of the servers that contacted it and proceed with its operation. - New C# mapping
An updated language mapping takes advantage of features from .NET 2.0, including generics. - IPv6 support
- Visual Studio 2008 support
- Desupporting Java2
Ice for Java 3.3 continues to support the Java2 language mapping but requires Java5 or later as the compiler and run time environment. - Thread per connection
This concurrency model was originally added to support the Glacier router, and it was also required by IceSSL for Java2 and .NET. Although it doesn't scale as well as the thread pool, thread per connection was useful for serializing requests on a connection. With the improvements provided by the background I/O enhancements, this concurrency model is no longer needed by the Ice run time or services. In Ice 3.3, thread per connection will either be deprecated or removed altogether.
0