Imagine you’re at an exclusive club. To get in, you first check with the bouncer (the HTTP preflight request) to make sure you’re allowed in. Only after approval can you step inside and enjoy the party. That’s exactly how HTTP preflight works when connecting TCP clients to AMPS via an HTTP proxy!

With this feature, TCP clients can seamlessly pass through an HTTP proxy—just like WebSockets—while maintaining AMPS’s high-performance messaging capabilities. Whether you’re working with Python, Java, C++, or C#, this feature opens up new possibilities for flexible and efficient integrations.

AMPS bookmark subscriptions provide a way for applications to resume subscriptions in the event of a disconnection or failure of either the application or server. With a bookmark subscription, the application side manages the correct point to resume the subscription by setting a BookmarkStore on the client, and then discarding messages from the store once the application is done processing them. The clients offer both a memory-based bookmark store (which does not persist when the application restarts) and a file-based bookmark store (which is persisted on the file system).

Those options work well for many AMPS deployments. In some deployments, though, no filesystem is available, but the application still needs to resume a subscription when it is restarted. This post explains how current versions of the AMPS client can use a topic in the AMPS State-of-the-World to store the point at which the application should be resumed. The post assumes a good working knowledge of resumable subscriptions (covered in detail in the AMPS User Guide and the AMPS Java Developer Guide), and also assumes some familiarity with the implementations of the AMPS clients.

There are several popular patterns for creating a replicated set of AMPS instances. One popular pattern is a "cascading mesh", or a set of instances that receives publishes in one set of instances and then distributes those messages to other sets of instances. This blog post describes a common approach to creating a mesh of this type, explains how the configuration works, and discusses the tradeoffs involved in this approach.

We wrote this several years ago, and it remains true: modern data processing systems are complex and often consist of several sub-systems from various vendors where each individual subsystem typically exposes some sort of monitoring interface with its own metrics, format, authentication and access control. In order to keep such complexity under control and be able to monitor whole system state in real-time and in the past, standard monitoring packages have emerged. More than ever, most customers we work with no longer build end-to-end monitoring systems themselves, but instead build custom dashboards using off-the-shelf monitoring software. It makes sense to focus on the metrics that are important to the business and the application rather than the low-level details of creating the framework.

From Day-1, we’ve built AMPS to be content aware, yet message-type agnostic. As such, we’re often asked which message-type we think is best. The best message type, in most situations, is dependent on the use-case. In this article, we drill-down into what factors you should consider when selecting a message type, the benefits/drawbacks of each message-type and the functionality trade-offs specifically when it comes to AMPS.

Over the last several days, a remote code execution vulnerability (CVE-2021-4428) has been reported in the popular Apache log4j package.

This is an extremely serious vulnerability, and is being actively exploited by attackers as of the publication of this posting.

AMPS is used for a wide variety of applications, from extreme low-latency applications with a latency budget of less than a millisecond roundtrip to applications that aggregate millions of fast changing records that intentionally conflate updates to reduce load on a user interface. All of these applications have one thing in common, though: AMPS runs on x64 Linux, so application developers need to have access to a Linux installation to develop against AMPS.

For sites (or developers) typically focused on Windows development, this can sometimes make it seem more difficult than necessary to get started with AMPS. Installing a virtualization product like VirtualBox or VMWare works well, but involves installing the virtualization software, choosing and manually installing a Linux distribution, and then dealing with what is effectively an entirely separate desktop and development system.

Last year we published a very popular grid comparison which provided a good overview of several web grid engines commonly used for modern web applications.

Even if you can't make it to the great outdoors, AMPS now makes it easy to visit a range of data in the transaction log.

For years, AMPS has had the ability to use a bookmark subscription to replay messages from the transaction log. A bookmark subscription begins at a bookmark -- a point in the transaction log -- and the subscription would continue until the point that the application unsubscribed.

Bookmark subscriptions allow applications to resume subscriptions after being disconnected without losing messages, and also provide a way to recreate the sequence of messages to an instance (for example, for auditing or backtesting purposes).

In real world systems, networks fail, components need to be replaced, servers need maintenance. Successful enterprise grade applications need to be designed with fault tolerance in mind! AMPS sets you up for success with features designed for robust fault tolerance and high availability.

Many things have changed in the webapp world since we last did a grid comparison, way back in 2017.

Scaling out your data processing using AMPS queues allows you to dynamically adjust how many workers you apply to your data based on your needs and your computing resources. Larger orders coming in or more events to process? Just spin up more subscribers to your AMPS queue and let them take their share of the load. AMPS dynamically adjusts how many messages it gives to each consumer based on their available backlog and message processing rate, and your work gets done without needing costly reconfiguration or re-partitioning.