1 Highly Available AMPS Client Programming 60East Technologies Copyright 2013 All rights reserved. 60East, AMPS, and Advanced Message Processing System are trademarks of 60East Technologies, Inc. All other trademarks are the property of their respective owners. Oct 29, Overview Building a highly available distributed system is hard. 60East AMPS technology greatly simplifies the chore when you use AMPS for message passing and filtering between nodes in your system. You can configure AMPS instances to replicate each other, allowing you to build a network of AMPS instances that will survive both network and system outages. To enable high availability throughout your entire system, however, your clients may need to know how to gracefully detect and recover from outages. This white paper discusses common failure modes and recovery options for all kinds of AMPS clients, and discusses support available in the AMPS Client Library. This paper discusses a replication architecture that works with all versions of AMPS that support replication. However, starting with AMPS , AMPS supports passthrough replication and replication groups, which greatly simplify replication. The instructions in this whitepaper will still work with AMPS , but are not the most efficient way to configure replication. Full details on replicaiton in and later are available in the User's Guide for those versions. 2. Recovering from Connectivity Outages One of the most basic problems in high availability communications is disconnection between distributed endpoints. An AMPS client, for example, may disconnect from a remote server for a variety of reasons: a physically disconnected network segment, a malfunctioning or misconfigured firewall or router, or even a down AMPS server. As a starting point, highly available AMPS clients need to reconnect to their existing server when a disconnection occurs. Disconnect Detection In most cases, you become aware that your connection is no longer alive when the TCP stack on your client system reports a failure to your application. With the AMPS Client Library, disconnections that 1
2 are detected and reported by the operating system result in an invocation of your disconnect handler. In AMPS, calling the setdisconnecthandler() method registers a disconnect handler that is called when a disconnection occurs: class MyDisconnectHandler implements ClientDisconnectHandler public void invoke(client c) c.connect(...); // try to reconnect to a server Client c = new Client(...); c.setdisconnecthandler(new MyDisconnectHandler()); Example 1. Disconnect Handling It can be difficult for your application to detect disconnection in a timely fashion. For example, unless your client has a heartbeat mechanism, a publisher or subscriber may remain running for minutes with an invalid connection before the operating system reports that the connection is not valid. AMPS version 3.3 and prior have no built-in client heartbeat mechanism; this feature is planned for version 3.4. Until then, AMPS clients may experience delays in the range of tens of minutes before a disconnect is discovered. Choosing a Client Name In AMPS, each client must log on with a unique client name. An AMPS instance will not allow multiple connections to log on with the same client name. When publishing, AMPS uses the client name as a key to record the highest sequence number seen from each client; when a publisher disconnects and reconnects to the same AMPS instance or a secondary, it should log on with the same client name as it used previously. AMPS will disconnect a client if it attempts to log on with a client name that is in use by another connection. With the AMPS Client Library, applications pass the client name to the Client constructor. If you are using the HAClient interface, pass the client name in the static methods createfilebacked or creatememorybacked. Choosing a Server Since disconnection can occur for so many reasons, an application needs to be smart about choosing a new server. In the case of disconnection with a single AMPS instance, the only choice is to attempt reconnection 2
3 to the same server, or to give up entirely. You face a more complicated situation, however, when building a system with a primary and secondary; the application s options are even more complex for choosing a new server when your system involves a mix of backup servers in the same rack and others in entirely different data centers. As a rule, you should always attempt to reconnect to the primary when a disconnection occurs. Network hiccups happen even when both the client and server hosts are healthy. Choose to move on to secondary servers only when reconnection to the primary fails. In most cases, your code should prefer a secondary that is close by rather than far away; but it is important to keep this logic as simple as possible, since the code for choosing a new server will be among the hardest in your application to fully test. The AMPS Client Library allows you to encapsulate your logic for choosing a server and reuse it across multiple applications, by implementing the ServerChooser interface and using it with the HAClient. You provide the ServerChooser, both to establish an initial connection and to choose an alternate connection. The HAClient works by implementing a disconnect handler for you, and by interacting with the ServerChooser. The reference implementation, DefaultServerChooser, keeps a list of URIs to connect with; upon an initial disconnection, it attempts to reconnect to the previously connected server, and if that fails, it keeps trying alternates in its list. You can use this reference implementation out of the box, extend it for your own needs, or create your own ServerChooser from scratch. Here is an example using the reference implementation: HAClient haclient = HAClient.createMemoryBacked(...); DefaultServerChooser myserverlist = new DefaultServerChooser(); myserverlist.add("tcp://primary.amps:9004/fix"); myserverlist.add("tcp://seconday.amps:10000/fix"); myserverlist.add("tcp://far.away.amps:9004/fix"); haclient.setserverchooser(myserverlist); haclient.connectandlogon(); // After this point, the haclient will // automatically atttempt reconnection // and connection to the secondary servers // provided by "myserverlist". Example 2. HA Client - Server Chooser Implementing your own ServerChooser can create a distinct advantage since you will be able to incorporate knowledge about the particulars of the local network environment. In large organizations with multiple AMPS deployments, a central team may be responsible for implementing a custom ServerChooser that utilizes proprietary knowledge to provide even greater reliability and efficiency than the Default- ServerChooser. Contact your site s AMPS team for more details. Establishing a new connection after connectivity is broken is an important part of creating highly available AMPS clients in nearly every scenario. Though AMPS does not segregate workloads, most AMPS clients 3
4 are primarily either publishers or subscribers. For the remainder of this white paper, we will focus first on issues specific to publishers, followed by issues specific to subscribers. 3. Reliable Publishing A reliable publisher must ensure that it actually succeeds in publishing the messages that it intends to publish. Before talking about ways to ensure publication, we will review a few concepts that are covered in more detail in the AMPS User s Guide. Publishing Acknowledgment In a non-ha publish, a publisher simply sends a publish message to an AMPS server; the AMPS server does not send an acknowledgement ( ACK ) back to the client. This mode of publishing allows for maximum performance, but with no guarantees. What happens if the AMPS server does not receive your message? What if the AMPS server goes down before it can persist the message or send it on to subscribers? In order to ensure that messages are seen by AMPS and do not need to be republished, a publisher can supply a sequence number on published messages. The publisher s sequence numbers uniquely identify each message, and enable the publisher to request a persisted ACK from the server indicating that AMPS has both received the message and persisted it in the transaction log. Sequence numbers are monotonically increasing integers, and must begin with the last value used by the client + 1. Publishers are responsible for determining and maintaining this sequence. If a disconnect occurs before the publisher receives the server s acknowledgement, then the publisher must re-publish all of the unacknowledged messages on the new connection after reconnection occurs. Once a publisher begins supplying sequence numbers on published messages, it must continue to do so for the remainder of its lifetime. To maximize performance in this mode of publishing, AMPS does not send a separate ACK for each message published. Instead, AMPS sends periodic ACK message to a publisher containing the last sequence number that has been persisted; a client can safely use this and disregard all of the messages with sequence numbers less than or equal to this value. During publisher recovery, AMPS will always return the last sequence number it has acknowledged in the previous connection, which is likely lower than the highest sequence number it has seen from that publisher. As a result, AMPS is likely to consider the first few replayed messages as duplicates. In support of this mechanism, AMPS will inform a publisher about the last sequence number it has seen from that publisher when logging on. For example, if a publisher has published messages, 1, 2, 3 and 10, and then disconnected, AMPS will tell that publisher (upon a subsequent connection) that the sequence number is 10, so that the publisher can begin from the new value. Likewise, if upon reconnection the 4
5 server informs the publisher that the most recent sequence number observed is 2, then the publisher is responsible for re-publishing 3 and 10 to the server. Recovering from Disconnect or Server Failure As noted above, AMPS expects a highly available publisher to be able to republish any messages for which AMPS has not yet sent an ACK. To fulfill this expectation, publishers must either store or be able to re-create previously published messages. To implement such a mechanism with reasonable performance, most publishers will need to follow these recommendations: 1. Keep an in-memory store of the contents of messages and their corresponding sequence numbers. Just before sending a message to the server, the publisher must calculate a new sequence number, and store it along with the data and topic. This code path will occur once per sent message, so its performance must be optimal. 2. When a persisted ACK arrives from the server, free up any space held in this store by messages whose sequence number is less than or equal to the one sent in the ACK. This code path will occur frequently as well, though typically less often than one per message (a ratio of 1:10 to 1:100 is expected, but AMPS provides no guarantees). 3. When logging on to the server (either in the case of an initial connection or a re-connection), a publisher should use the sequence number returned by AMPS to calculate a starting point for the sequence numbers on new messages. AMPS will immediately discard messages sent with sequence numbers less than or equal to the one supplied by the server on logon, considering them to be duplicates of previously received messages. 4. When recovering from a disconnection, if the server returns a sequence number less than or equal to the most recent message you published, you must re-publish each of the messages that the server has not yet seen (or else, they are lost forever). If you built your publisher on the AMPS Client Library, all of this functionality exists in the MemoryPublishStore, which the client library creates for you when using a memory-backed HA client: // Creates a memory-backed HA client that tracks // bookmarks and subscriptions in memory. MessageHandler handler = new MyHandler(); HAClient myclient = HAClient.createMemoryBacked("myClient"); // Add your instances to the client. DefaultServerChooser chooser = new DefaultServerChooser(); chooser.add("tcp://ubuntu.local:9004/fix"); chooser.add("tcp://backupampsinstance:9004/fix"); myclient.setserverchooser(chooser); myclient.connectandlogon(); // These messages are all stored in memory // while we await an ACK from AMPS. 5
6 for(int i = 0; i < 100; i++) myclient.publish("sometopic", String.format("12345=%d", i)); Example 3. HA Publisher Client In this example, each of the 100 published messages are stored in memory until the AMPS client receives acknowledgement from the server that it has received and persisted them. If a disconnect and reconnect occurs, the AMPS client will automatically re-publish any messages that need to be re-published, based on the rules above. The AMPS client automatically calculates and manages the sequence number for published messages. Safe Shutdown When implementing a short-lived publisher, it is important not to shut down until you are sure that the AMPS server has acknowledged all messages that you have published. If the publisher shuts down before this, it runs the risk of message loss -- for example, the AMPS server might also shut down, and messages that it has not yet received or persisted may be lost for good. Before shutting down, well-behaved publishers will examine the last ACK received from AMPS, to verify that it is equal to the sequence number on the last published message. If it is not, the publisher should simply wait; assuming the connection does not fail, AMPS will eventually send the final ACK, and you can proceed with shutting down. If you choose to implement a timeout mechanism, ensure that the publisher will attempt to reconnect after a timeout expiration and that it checks the returned sequence number in the logon, replaying any messages that the server has not yet seen. To aid in this aspect of publisher implementation, the AMPS Client Library provides a facility to inquire how many unpersisted (unacknowledged) messages remain. You can choose to wait for this value to become 0 before exiting: for(int i = 0; i < 100; i++) myclient.publish("sometopic", String.format("12345=%d", i)); // Just wait to hear back from the server. while(myclient.getpublishstore().unpersistedcount() > 0) Thread.yield(); myclient.disconnect(); Example 4. HA Publisher checking for unacknowledged messages 6
7 Untimely Publisher Death Your publisher may terminate before you expect it to. Perhaps, for example, another user kills your process, or your process terminates with a fatal error, or the operating system kills your process because it runs out of resources. In such scenarios, your publisher may exit before it has received acknowledgement of all of the messages it attempted to publish. Combined with a server failure at roughly the same time, this could result in lost messages. To guard against losing messages when a publisher goes down, a publisher must persist messages outside its process, typically to disk. If a publisher exits, a new process can start, log on, and compare the sequence number returned by the server to the messages stored on disk. The publisher replays any messages that were stored with a sequence number higher than the one returned by the AMPS server. Publishers that write their messages to disk before publishing have greater reliability, but lower performance. Efficient use of disk resources, both in terms of overall footprint and IOPS, are critical in implementing a high-performance publish store. If you wish to protect against host or operating system failure, an additional overhead of flushing buffers to disk must occur as well, further lowering performance. The AMPS Client Library includes a default, extensible implementation of a disk-backed publish store in the PublishStore class. It is instantiated for you when using the createfilebacked method of HAClient: // Creates a file-backed HA client that tracks // bookmarks and subscriptions on disk MessageHandler handler = new MyHandler(); HAClient myclient = HAClient.createFileBacked( "myclient", // client name "myclient.publish", // publish filename "myclient.subscribe" // subscribe filename ); //1 myclient.connectandlogon(); //2 for(int i = 0; i < 100; i++) myclient.publish("sometopic", String.format("12345=%d", i)); Example 5. Memory-backed HA Publisher In this example, the publisher writes each of the 100 messages to the myclient.publish file on disk before sending them to the server. If the publisher process terminates before the server can acknowledge the published messages, then the data of those messages remains on disk. When the publisher restarts, the createfilebacked method will reload the myclient.publish file (by, in turn, creating a PublishStore object), on the line marked //1. When the publisher successfully logs back on to a server (line //2), the AMPS client will automatically compare the sequence number returned by AMPS 7
8 with the loaded contents of myclient.publish, and automatically re-publishes any messages that the server needs. 4. Subscriber Concerns Once a client places a subscription with AMPS, the AMPS instance ensures that it sends every matching message to that client. If the subscriber loses its connection to AMPS, the subscriber will never see any of the messages that AMPS processed while the subscriber was away. To allow clients to resubscribe at the point where they originally lost connectivity, AMPS provides a bookmark mechanism whereby it stamps messages with a string (the bookmark) that uniquely identifies the message and its order relative to other messages AMPS has seen. By default, AMPS saves network bandwidth by omitting the bookmark on messages that it sends to a subscriber. Subscribers that are interested in a bookmark must supply a bookmark when issuing their subscribe or delta_subscribe command, supplying one of the following as the bookmark: A valid bookmark string. Valid bookmark strings identify a message and publisher id. AMPS will begin the subscription at the point in the transaction log immediately following this bookmark. The value 0. This special value represents the epoch. AMPS will begin the subscription with the first message in its transaction log. The value 0 1. AMPS interprets this value as a request to begin the subscription with the next message; that is, now. AMPS will not perform a replay of past messages. To implement a client that does not lose messages upon reconnect, the client must retain the latest bookmark it has seen on each subscription and, when re-subscribing, supply this bookmark in the header field of the subscribe command. If an application requires resilience to subscriber failure, the application should keep the most recently seen bookmark for each subscription on disk. If performance is the greatest concern of the application and the ability to ensure no lost messages on subscriber failure is not required, then the most recently seen bookmark can simply be kept in memory. Resubscribing after Disconnect If disconnection occurs, the AMPS server does not automatically reinstate the subscriptions when your client reconnects. Each subscriber is responsible for reissuing subscriptions that it wishes to continue; and for bookmark subscriptions, these must include the bookmark at which the subscription should resume. The AMPS Client Library provides a facility for remembering the subscriptions your application has made and reissuing them on reconnect in the SubscriptionManager interface. AMPS provides a default implementation in the MemorySubscriptionManager class, which the client automatically creates for you when you use the HAClient: MessageHandler handler = new MyHandler(); HAClient myclient = HAClient.createMemoryBacked("myClient" // client name 8
9 ); DefaultServerChooser chooser = new DefaultServerChooser(); chooser.add("tcp://localhost:9004/fix"); myclient.setserverchooser(chooser); myclient.connectandlogon(); myclient.subscribe(handler, "sometopic", 10000); // sometopic will be resubscribed to, even // if we disconnect (and reconnect). Example 6. Subscribe with Reconnect In this example, after the subscribe() call returns successfully, the HAClient will resubscribe to sometopic whenever a disconnection and subsequent reconnection occurs. When using the HAClient.createFileBacked() method to create a filebacked HA client, the list of subscriptions is kept only in memory, and the AMPS client does not automatically re-create subscriptions when your process restarts. If you would like to implement an application that is capable of automatically recreating an arbitrary set of subscriptions on start-up, then you should implement the SubscriptionManager interface, writing subscriptions to disk. On recovery of the file in the new subscriber process, your new Subscription- Manager must determine how to bind previous subscriptions to new MessageHandler instances, and then re-create the desired subscriptions on the new Client. Message Receive Order versus Processing Order Some subscribers need to process messages in a different order from which AMPS sends them. Imagine a subscriber that calculates statistics on a moving window of trades. At any given time, it needs to wait for the current window to fill up before calculating and issuing the new output; once it has computed and delivered the output, it can free up the messages and resources associated with that window. This hypothetical subscriber might need to have multiple windows open at any given time as well, because messages do not necessarily arrive in the order that real events occur. If this hypothetical subscriber failed and restarted, it would need to re-subscribe to AMPS to get messages corresponding to all of the windows that were inprogress at the time it went down. It would be important not to lose any messages that occurred while the subscriber was down. It would also be important not to receive messages again for any windows that are already closed even though those messages might have originally been delivered after messages for windows that are open. In short, the application should not reprocess all messages after the re-subscribe point; only those messages that the application has not yet discarded should be reprocessed. In this complex (but common) scenario, the order of message processing is different from the order of message reception. Clients seeking to adequately support this scenario must store both a bookmark to 9
10 resubscribe to the earliest message that the application has not discarded along with the bookmarks associated with the discarded messages after that point. After a resubscribe, the application should filter out incoming messages that have bookmarks matching those already discarded. The AMPS Client Library provides built-in support for resubscribing to a point in time with filtering of already discarded messages through the BookmarkStore interface. The AMPS Client Library provides three implementations of the BookmarkStore: MemoryBookmarkStore implements an in-memory store that allows you to automatically re-subscribe where you left off, in case of a connection failure or server outage; LoggedBookmarkStore implements a disk-based store that logs a bookmark for each incoming message and each discarded message, in case of network, server, or subscriber failure; RingBookmarkStore implements a much faster disk-based store that does not filter discarded messages after the resubscribe point, thus potentially delivering duplicates if your application processes messages in a different order than it receives them. When using a BookmarkStore, it is incumbent upon your application to call the store s discard() method when it is logically finished with a message, so that AMPS does not redeliver the message upon resubscribe: public void invoke(message message)... myclient.getbookmarkstore().discard( message.getsubidraw(), // The subscription ID message.getbookmarkseqno() // The sequence number of this message. );... Example 7. Bookmark Discard A subscriber must call discard() as soon as possible after processing a message. If a subscriber uses a bookmark store but fails to call discard() on messages as they are processed, recovery will always result in duplicate messages. Publisher Duplicates It is possible for a subscriber to see duplicate messages from AMPS, even when it properly re-subscribes to the bookmark it last saw before disconnection. The following conditions are necessary for this situation to occur: The subscriber must have specified the live option when placing the subscription, indicating that AMPS should deliver matching messages before they are stored in the transaction log; 10
11 There must be a failure of connectivity or an AMPS server that causes publishers and subscribers to fail over to a secondary. If this scenario occurs, it is possible for publishers to replay a message that the new AMPS instance does not recognize as a duplicate, but that subscribers have already seen. It is therefore possible that the subscriber will, upon connection to the secondary and re-subscription, observe messages arriving from the new AMPS instance that were already delivered by the old instance, thus resulting in apparent duplicates. To prevent this scenario, subscribers need to determine if an incoming bookmark is an unexpected duplicate of one already seen. Subscribers must parse the bookmark into the publisher ID and sequence number components, which are separated by the (pipe) character. Subscribers should filter out messages with out-of-order sequence numbers from a given publisher ID. For example, if a subscriber receives messages from the same publisher with sequence numbers 1000 and 1002 followed by 999, it must discard 999. If the subscriber builds on the AMPS Client Library, then nothing special is required to implement this logic. The following implementations allow you to track the latest message seen per publisher and to discard messages that have already been sent by a previous AMPS instance: LoggedBookmarkStore: used when you invoke HAClient.createFileBacked() MemoryBookmarkStore: used when you invoke HAClient.createMemoryBacked() 5. Conclusion In this white paper, we looked at the issues that AMPS clients face in implementing high availability. If you choose to implement your own client for AMPS, these considerations will be of utmost importance to you as you decide exactly what level of reliability to target. If you build your application with the AMPS Client Library, you can greatly reduce complications by using HAClient along with the supplied PublishStore and BookmarkStore implementations. No matter what, understanding the choices and tradeoffs involved in implementing high availability will certainly help you to build the most robust and highestperformance solution. FOR MORE INFORMATION, CONTACT: 60East Technologies [http://www.crankuptheamps.com] (888)
FioranoMQ 9 High Availability Guide Copyright (c) 1999-2008, Fiorano Software Technologies Pvt. Ltd., Copyright (c) 2008-2009, Fiorano Software Pty. Ltd. All rights reserved. This software is the confidential
DHCP Failover: Requirements of a High-Performance System A white paper by Incognito Software April, 2006 2006 Incognito Software Inc. All rights reserved. Page 1 of 6 DHCP Failover: Requirements of a High-Performance
UserLock advanced documentation 1. Agent deployment with msi package or with the UserLock deployment module The UserLock deployment module doesn t deploy the msi package. It just transfers the agent file
2014 Kepware Technologies 2 RedundancyMaster Help Table of Contents Table of Contents 2 Introduction 4 System Requirements 10 Accessing the Administration Menu 11 Setting Up Redundancy 11 Adding Redundancy
Backup and Redundancy White Paper NEC s UC for Business Backup and Redundancy allow businesses to operate with confidence, providing security for themselves and their customers. When a server goes down
www.novell.com/documentation Troubleshooting: 2 Solutions to Common Problems GroupWise 8 August 31, 2009 Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or
The NewSQL database you ll never outgrow Integrating with Hadoop Hadoop is an open source framework for managing and manipulating massive volumes of data. is an database for handling high velocity data.
Intel RAID Controllers Best Practices White Paper April, 2008 Enterprise Platforms and Services Division - Marketing Revision History Date Revision Number April, 2008 1.0 Initial release. Modifications
Protect SAP HANA Based on SUSE Linux Enterprise Server with SEP sesam Many companies of different sizes and from all sectors of industry already use SAP s inmemory appliance, HANA benefiting from quicker
CHAPTER 10 This chapter provides Content Distribution Manager database backup and ACNS software recovery procedures. This chapter contains the following sections: Performing Backup and Restore Operations
WHITE PAPER Recovery Behavior of Communication Manager from Control Network Outages May 2007 Table of Contents Section 1: Introduction... 1 Section 2: IPSI Socket Sanity Timeout Feature... 1 2.1 Before
SAP HANA Backup and Recovery (Overview, SPS08) Andrea Kristen, SAP HANA Product Management October 2014 Disclaimer This presentation outlines our general product direction and should not be relied on in
High Availability Essentials Introduction Ascent Capture s High Availability Support feature consists of a number of independent components that, when deployed in a highly available computer system, result
Operating System Microsoft Windows 2000 Terminal Services Licensing Technology White Paper Abstract This white paper provides an introduction to Terminal Services Licensing, the client license management
Remote Copy Technology of ETERNUS6000 and ETERNUS3000 Disk Arrays V Tsutomu Akasaka (Manuscript received July 5, 2005) This paper gives an overview of a storage-system remote copy function and the implementation
Configuring the Redundancy Feature in a Spectralink IP-DECT Server 6500 Configuring the Redundancy Feature in a Spectralink IP-DECT Server 6500 Application Note Page 1 Introduction The redundancy feature
Whitepaper: Back Up SAP HANA and SUSE Linux Enterprise Server with SEP sesam email@example.com www.sepusa.com Table of Contents INTRODUCTION AND OVERVIEW... 3 SOLUTION COMPONENTS... 4-5 SAP HANA... 6 SEP
Highly Available Mobile Services Infrastructure Using Oracle Berkeley DB Executive Summary Oracle Berkeley DB is used in a wide variety of carrier-grade mobile infrastructure systems. Berkeley DB provides
Administrator Guide VMware vcenter Server Heartbeat 6.3 Update 1 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition.
ASG-Rochade Backing up Rochade Databases Quick Start Guide Version 7.00.006 March 5, 2007 ROC0600-700 This publication contains information about backing up databases of ASG-Rochade (herein called Rochade).
Disaster Recovery Solutions for Oracle Database Standard Edition RAC A Dbvisit White Paper Copyright 2011-2012 Dbvisit Software Limited. All Rights Reserved v2, Mar 2012 Contents Executive Summary... 1
BrightStor ARCserve Backup for Windows Agent for Microsoft SQL Server r11.5 D01173-2E This documentation and related computer software program (hereinafter referred to as the "Documentation") is for the
Smart Tips Enabling WAN Load Balancing Overview Many small businesses today use broadband links such as DSL or Cable, favoring them over the traditional link such as T1/E1 or leased lines because of the
Deploying Remote Desktop Connection Broker with High Availability Step-by-Step Guide Microsoft Corporation Published: May 2010 Abstract This guide describes the steps for configuring Remote Desktop Connection
Comprehensive List of XenDesktop Event Log Entries VDA Events 1200 Error Exception '%1' of type '%2' while starting the service. The service will now stop. When VDA fails to initialise or start. Renaming
Backup and Recovery Scenarios for Oracle WebLogic Server: 10.3 An Oracle White Paper January, 2009 Maximum Availability Architecture Oracle Best Practices For High Availability Backup and Recovery Scenarios
Backup and Recovery What Backup, Recovery, and Disaster Recovery Mean to Your SQL Anywhere Databases CONTENTS Introduction 3 Terminology and concepts 3 Database files that make up a database 3 Client-side
TCP Session Management (SesM) Protocol Specification Revision Date: 08/13/2015 Version: 1.1e Copyright 2015 Miami International Securities Exchange, LLC. All rights reserved. This constitutes information
WHITE PAPER: ENTERPRISE SOLUTIONS Symantec Backup Exec Continuous Protection Server Continuous Protection for Microsoft SQL Server Databases White Paper: Enterprise Solutions Symantec Backup Exec Continuous
CASE STUDY: Oracle TimesTen In-Memory Database and Shared Disk HA Implementation at Instance level -ORACLE TIMESTEN 11gR1 CASE STUDY Oracle TimesTen In-Memory Database and Shared Disk HA Implementation
Napster and Gnutella: a Comparison of two Popular Peer-to-Peer Protocols Anthony J Howe Supervisor: Dr Mantis Cheng University of Victoria February 28, 2002 Abstract This article presents the reverse engineered
Parallels Cloud Storage White Paper Performance Benchmark Results www.parallels.com Table of Contents Executive Summary... 3 Architecture Overview... 3 Key Features... 4 No Special Hardware Requirements...
5 CHAPTER This chapter describes how to set the firewall mode to routed or transparent, as well as how the firewall works in each firewall mode. This chapter also includes information about customizing
This product is protected by U.S. and international copyright and intellectual property laws. This product is covered by one or more patents listed at http://www.vmware.com/download/patents.html. VMware
Distributed Systems (CS236351) Winter, 2014-2015 Exercise 3 Due date: 11/1/15, 23:59 1 System overview In this exercise, you are going to develop another version of the basic resource management service,
CA ARCserve Backup for Windows Agent for Sybase Guide r16 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation
Firewall Port Handling in TENA Applications The purpose of this report is to describe the manner in which TENA applications handle communications using TCP. This report will also present some insight for
Technical white paper Protect Microsoft Exchange databases, achieve long-term data retention HP StoreOnce Backup systems, HP StoreOnce Catalyst, and Symantec NetBackup OpenStorage Table of contents Introduction...
PATROL Console Server and RTserver Getting Started Supporting PATROL Console Server 7.5.00 RTserver 6.6.00 February 14, 2005 Contacting BMC Software You can access the BMC Software website at http://www.bmc.com.
Highly Available Service Environments Introduction This paper gives a very brief overview of the common issues that occur at the network, hardware, and application layers, as well as possible solutions,
FactoryTalk View Site Edition V5.0 (CPR9) Server Redundancy Guidelines This page left intentionally blank. FTView SE 5.0 (CPR9) Server Redundancy Guidelines.doc 8/19/2008 Page 2 of 27 Table of Contents
MERTECH DATA SYSTEMS, INC 18503 Pines Boulevard, Suite 312 Pembroke Pines, FL 33029, USA Tel: 1-954-585-9016 Fax: 1-866-228-1213 www.mertechdata.com Contents Supporting MS SQL Server Failover Using Database
Archive Manager Publication Date: November, 2015 All Rights Reserved. This software is protected by copyright law and international treaties. Unauthorized reproduction or distribution of this software,
WHITE PAPER Citrix XenServer High Availability for Citrix XenServer Enhancing XenServer Fault Tolerance with High Availability www.citrix.com Contents Contents... 2 Heartbeating for availability... 4 Planning
Business Continuance of SAP Solutions on Vmware vsphere This product is protected by U.S. and international copyright and intellectual property laws. This product is covered by one or more patents listed
Tomás P. de Miguel DIT- 15 12 Internet Mobile Market Phone.com 15 12 in Millions 9 6 3 9 6 3 0 1996 1997 1998 1999 2000 2001 0 Wireless Internet E-mail subscribers 2 (January 2001) Mobility The ability
High Availability Solutions for the MariaDB and MySQL Database 1 Introduction This paper introduces recommendations and some of the solutions used to create an availability or high availability environment
Windows Server 2008 R2 Hyper-V Live Migration Table of Contents Overview of Windows Server 2008 R2 Hyper-V Features... 3 Dynamic VM storage... 3 Enhanced Processor Support... 3 Enhanced Networking Support...
Configuring the Redundancy Feature in a KIRK Wireless Server 6000 Application Note Version 1.7 l April 2014 l 14205401 Page 2 Introduction The redundancy feature of the KIRK Wireless Server 6000 solution
Multi Stage Filtering Technical Brief With the increasing traffic volume in modern data centers, largely driven by e-business and mobile devices, network and application performance monitoring has become
Restoring Microsoft SQL Server 7 Master Databases A damaged master database is evident by the failure of the SQL Server to start, by segmentation faults or input/output errors or by a report from DBCC.
Computer Networks Chapter 5 Transport Protocols Transport Protocol Provides end-to-end transport Hides the network details Transport protocol or service (TS) offers: Different types of services QoS Data
Websense Support Webinar: Questions and Answers Configuring Websense Web Security v7 with Your Directory Service Can updating to Native Mode from Active Directory (AD) Mixed Mode affect transparent user
Configuring and Integrating Oracle The Basics of Oracle 3 Configuring SAM to Monitor an Oracle Database Server 4 This document includes basic information about Oracle and its role with SolarWinds SAM Adding
TIBCO StreamBase High Availability Deploy Mission-Critical TIBCO StreamBase s in a Fault Tolerant Configuration TIBCO STREAMBASE HIGH AVAILABILITY The TIBCO StreamBase event processing platform provides
Exchange Data Protection: To the DAG and Beyond Whitepaper by Brien Posey Exchange is Mission Critical Ask a network administrator to name their most mission critical applications and Exchange Server is
Citrix Access Gateway Plug-in for Windows User Guide Access Gateway 9.2, Enterprise Edition Copyright and Trademark Notice Use of the product documented in this guide is subject to your prior acceptance
NetIQ AppManager for Self Monitoring UNIX and Linux Servers (AMHealthUNIX) Management Guide September 2014 Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND
Industry White Paper Ensuring system availability in RSView Supervisory Edition applications White Paper Ensuring system availability in RSView Supervisory Edition applications Rockwell Software, Visualization
The World's Leading Software for Label, Barcode, RFID & Card Printing White Paper Licensing for BarTender s Automation Editions Understanding Printer-Based Licensing and How to Configure Seagull License
Intellicus Cluster and Load Balancing (Windows) Version: 7.3 Copyright 2015 Intellicus Technologies This document and its content is copyrighted material of Intellicus Technologies. The content may not
GSM Cellular Engine GSM TCPIP Application Notes GSM_TCPIP_AN_V1.1 Document Title GSM TCPIP Application Notes Version 1.1 Date 2011-09-22 Status Document Control ID Release GSM_TCPIP_AN_V1.1 General Notes
Data Management in the Cloud Ryan Stern firstname.lastname@example.org : Advanced Topics in Distributed Systems Department of Computer Science Colorado State University Outline Today Microsoft Cloud SQL Server
Dell High Availability Solutions Guide for Microsoft Hyper-V www.dell.com support.dell.com Notes and Cautions NOTE: A NOTE indicates important information that helps you make better use of your computer.
Automatic Service Migration in WebLogic Server An Oracle White Paper July 2008 NOTE: The following is intended to outline our general product direction. It is intended for information purposes only, and
SCHOONER WHITE PAPER Top 10 Reasons why MySQL Experts Switch to SchoonerSQL - Solving the common problems users face with MySQL About Schooner Information Technology Schooner Information Technology provides
Your consent to our cookies if you continue to use this website.