Greetings! Let's get you up to speed with what has been going on at Caucho!
Baratine 0.9 Release
We pride ourselves on being able to identify and provide the latest implementation technology for web applications. Considering the sheer number of devices that can now access web apps, the landscape for building these applications is constantly evolving. In order to respond to the growing number of connections, more emphasis is being placed on the asynchronous ability of new apps and this is also a major focus for us.
Currently we are working on what we see as the de facto standard for building fully asynchronous, scalable, and independent SOA services in Baratine. We see this technology as the dominant driver of what new applications will need and much of our time has been devoted to building this platform. The upcoming Baratine 0.9 release moves us very close to production ready. You can find more news about Baratine on http://baratine.io or below in the Baratine section.
Two early projects we are working on as proof of concepts for the Baratine platform are:
• Baratine + Lucene – For indexing and searching files stored in the Baratine Distributed File System
• Bartwis – A Baratine clone of a Twitter-toy clone written in PHP & Redis
These two projects are close to reaching their final stage and can be explored currently on the baratine github (https://github.com/baratine). We are very excited to see how the community will expand on these applications within the Baratine environment.
The Lucene + Baratine plugin illustrates Baratine’s ability to take a previously written library, that was designed as a fully blocking and locking service, and with just a few lines of Baratine coding, transform it into a fully asynchronous service.
The Bartwis project highlights Baratine’s flexibility and performance. We have fully implemented Redis in Baratine to show the magnitude of Baratine’s capabilities. In this example, Baratine transforms simple POJO classes into fully redundant services under the hood, so users are able to use this application to achieve Redis-like functionality with no restrictions on what data structures are supported. In fact, if developers found a particular data structure more efficient than what is available in Redis today, they could simply implement that structure as a Baratine service and receive the microservice and asynchronous capabilities of Baratine automatically.
Of course this is just the beginning, head over to our github and take a look at the projects for yourself today!
• jsee: self signed cert should support Firefox and Chrome default cipher-suites(#5884)
• jsee: self signed cert should check expire (#5885)
• class-loader: excessive reread of jar certificates (#5850, rep by konfetov)
• log: add sanity check for log rollover (#5845, rep by Keith F.)
• deploy (git): use utf-8 to store path names (#5874, rep by alpor9)
• websocket: setTimeout was being overridden by Port keepaliveTimeout (#5841, rep by A. Durairaju)
• jni: on windows, skip JNI for File metadata like length (#5865, rep by Mathias Lagerwall)
• db: isNull issues with left join (#5853, rep by Thomas Rogan)
• websocket: check for socket close on startTextMessage (#5837, rep by samadams)
• log: when log rollover fails, log to stderr (#5855, rep by Rock)
• filter: allow private instantiation (#5839, rep by V. Selvaggio)
• rewrite: added SetRequestCharacterEncoding (#5862, rep by Yoon)
• health: change health check timeout to critical instead of fatal to allow for development sleep (#5867)
• alarm: timing issue with warnings and alarm extraction (#4854, rep by Shinomiya Nobuaki)
• session: orphan deletion throttling needs faster retry time (rep by Thomas Rogan)
• mod_caucho: slow PUT/POST uploads with Apache 2.4 (#5846, rep by Stegard)
Resin v3 to v4 Migration
Earlier this year we held an Advanced Resin 4 training session going over the many aspects of Resin that can be utilized for high availability, resilient recovery, and post mortem analysis. Quite a few deployments are still utilizing Resin 3. While Resin 3 is a great platform, we’d like to encourage our users to move to the better performing Resin 4 platform.
Resin 4 has significant features including cloud support, application health visibility, and unprecedented high availability.
Understandably, there might be current technologies in your application stack that are preventing you from upgrading. Resin 3 support will be sunset in January 2016, we’d like to offer an upgrade path for our current users. If you are currently running Resin 3 and would like a review of your application stack to gauge what would be necessary in an upgrade, contact firstname.lastname@example.org. Our developers will work with you to mitigate any potential conflicts with your current stack and also help layout similar configurations to get you up and running on Resin v.4 in no time!
Resin 5 is currently in alpha as we continue to implement the Servlet 3.1 (4.0 when available), HTTP 2.0, and WebSocket specs.
Resin 4 Tip
Looking to setup remote monitoring software with your Resin installation?
The /resin-admin directory, contains an index page with a “rest” example toward the bottom. You can customize this rest page to get the information about your application that you are interested in.
Equivalently, by browsing to the /php/admin/WEB-INF/php/*.rest pages, you can get an example of how JMX values can be extracted from Resin in simple PHP pages. These can then return the result in a format for one of the standard monitoring software plugins such as Nagios.
Copyright (c) 1998-2015 Caucho Technology, Inc. All rights reserved.
Caucho®, resin®, quercus® and baratineTM are registered trademarks of Caucho Technology, Inc.