text:
Technology for sharing data among multiple virtual machines in a cluster of virtual machines is disclosed. Each virtual machine identifies "managed" objects of an instance of an application running at the virtual machine. The managed objects are objects for which state information is to be replicated at the other virtual machines in the cluster on which other instances of the application are running. Operations performed by an instance of one application which affect the state of managed objects are detected and distributed. A computer-implemented method for maintaining consistent object states at different virtual machines includes receiving managed object state information from a first virtual machine including a first instance of an application; creating a representation of each of the managed objects; and responsive to the received information, communicating state information to at least a second virtual machine on which a second instance of the application is running to replicate the state information at the second virtual machine.
1. A computer-implemented method for allowing different instances of an application to execute in different virtual machines, comprising:
providing a clustering agent interfacing with a plurality of virtual machines, each virtual machine running at least one instance of the application, each instance of the application accessing a plurality of objects;
configuring one or more managed objects selected from the plurality of objects, the managed objects comprising a subset of the plurality of objects, said configuring identifying operations which may affect the one or more managed objects in a each instance of application on each virtual machine;
detecting application operations performed on the one or more managed objects by any instance of the application which affect state information of the managed objects; and
communicating the application operations detected in one application instance in one virtual machine to a central manager for use in replicating the managed object state information to others of said virtual machines.
2. The computer-implemented method of
the step of configuring comprises defining a root object identifying and child objects which can be reached from the at least one root object.
3. The computer-implemented method of
the state information is replicated by updating a local instance of the managed object at the second virtual machine with said operations.
4. The computer-implemented method of
5. The computer-implemented method of
6. The computer-implemented method of
instrumenting byte code of each instance of the application to perform the steps of identifying and detecting.
7. The computer implemented method of
8. A computer-implemented method for maintaining consistent data at different virtual machines, comprising:
providing one or more clustering agents interfacing with a plurality of virtual machines, each of the plurality of virtual machine interfacing with a local instance of an application associated with the virtual machine, each application accessing a plurality of objects at the virtual machine;
receiving application operations describing events affecting a local instance of a managed object state from any one of the virtual machines at a central controller;
creating a representation of each of the managed objects using the application operations at the central controller, the representation describing the object state; and
communicating update operations describing the detected operations on the managed object to others of said plurality of virtual machines to replicate the managed object state in a local instance of the managed object on others of the virtual machines.
9. The computer-implemented method of
the managed objects are identified by an object graph at one of the virtual machines which includes at least one root object and objects reachable from the at least one root object.
10. The computer-implemented method of
the application operations comprise field set operations.
11. The computer-implemented method of
the application operations comprise method calls.
12. The computer-implemented method of
the managed objects are identified and detected by instrumented byte code of each instance of the application.
13. The computer implemented method of
14. The computer-implemented method of
receiving application operations describing a local instance of a managed object state from at least two of the virtual machines.
15. A computer-implemented method for maintaining consistent data at different virtual machines, comprising:
providing a clustering agent interfacing with a plurality of virtual machines, each of the plurality of virtual machine interfacing with a local instance of an application associated with the virtual machine, each application accessing a plurality of objects at the virtual machine;
on any one of the virtual machines,
identifying operations which may affect state in one or more managed objects in a first instance of an application on the one of the virtual machines;
detecting application operations performed on the one or more managed objects by the first instance of the application which affect the state information; and
communicating the application operations to a central manager for use in replicating the managed object state information at other virtual machines, and
on the central manager,
creating a representation of each of the managed objects using the application operations, the representation describing the object state; and
communicating update operations detected in one application instance in one virtual machine describing the object state information to at least a second virtual machine to replicate the managed object state in a local instance of the managed object on the second virtual machine.
16. The computer-implemented method of
the step of identifying includes defining a root object and generating an object graph at at least one virtual machine which includes the root object and objects reachable from the root object.
17. The computer-implemented method of
the state information is replicated by updating local objects at the second virtual machine using the application operations.
18. The computer-implemented method of
19. The computer-implemented method of
20. The computer-implemented method of
instrumenting byte code of the first instance of the application to perform the steps of identifying and detecting.
21. The computer implemented method of
This application claims the benefit of U.S. provisional patent application No. 60/684,610, filed May 25, 2005, titled "Terracotta Virtualization Server", and incorporated herein by reference.
The application is also related to the following co-pending applications, each of which is incorporated herein by reference:
(1) U.S. patent application Ser. No. 11/441,677, filed May 25, 2006, titled "Distributed Signaling in a Virtual Machine Cluster";
(2) U.S. patent application Ser. No. 11/441,676, filed May 25, 2006, titled "Creating Clustered Object State Using Synthetic Transactions".
(3) U.S. patent application Ser. No. 11/441,605, filed May 25, 2006, titled "Distributed Object Identity in a Virtual Machine Cluster";
(4) U.S. patent application Ser. No. 11/442,522 filed May 25, 2006, titled "Clustered Object State Using Field Set Operations";
(5) U.S. patent application Ser. No. 11/442,524, filed May 25, 2006, titled "Clustered Object State Using Logical Actions";
(6) U.S. patent application Ser. No. 11/442,523, filed May 25, 2006, titled "Lock Management for Clustered Virtual Machines".
Application developers have traditionally faced a number of challenges in horizontally scaling applications to multiple servers. Scaling is particularly useful to World Wide Web application developers who may, for example, require geographically distributed application servers to provide users with better performance. In one example, suppose a user of a web-based application logs on to a web site to change information in an existing user account. Typically, in a distributed application, one application server is selected to handle the transaction based on its geographical location, availability or other factors. The selected server accesses the account data and makes the requested changes locally and the updated data must then be shared with the other servers so that the user's future interactions with any of the servers will reflect the updates. Additionally, the fact that some servers may go offline while others come online must be considered.
This scaling challenge is faced by developers in many development environments, including developers using the popular Java development platform. The Java platform's goal in providing a platform independent environment is generally met by the fact that Java source code is compiled into an intermediate language called "bytecode," which can reside on any hardware platform. In order to run the bytecode, it must be compiled into machine code via a Java Virtual Machine (JVM). A JVM is a platform-independent execution environment that converts Java byte code into machine language and executes it. The JVM provides the developer with the tools necessary for multi-threaded applications, including thread support, synchronization and garbage collection.
Traditionally, application developers themselves have been required to account for scaling using common forms of inter-server communication in order to share objects amongst distributed JVMs. One form of communication is Remote Method Invocation (RMI), which is a set of protocols that enables Java objects to communicate remotely with other Java objects. Another form of communication is the Java Message Service (JMS), which is an Application Program Interface (API) for accessing enterprise messaging systems. JMS supports both message queuing and publish-subscribe styles of messaging. Java Temporary Caching (JCache) is a distributed caching system for server-side Java applications.
While each of these techniques allow the developer the flexibility to add scaling to their application, the conventional techniques require application code to be modified, resulting in significant added complexity and development costs. Further, the conventional techniques limit scalability of the application tier, are often quite slow, and tend to abuse database infrastructure for transient needs. Finally, the task of maintaining object identity is a challenge as multiple copies of the same object can be created at the different application servers.
An improved technology is needed for maintaining consistent data across virtual machines.
The technology herein, roughly described, provides a technique for sharing data among multiple virtual machines in a cluster of virtual machines.
Data sharing functionality is provided to application software which was designed for use on a single virtual machine. Various features which are provided include sharing of object state between virtual machines, flexible locking which is configurable at run-time, distributed method invocation and distributed signaling. In one approach, a data sharing agent or library on a virtual machine instruments the application code to provide the data sharing functionality. The data sharing agents include a lock manager, a transaction manager, an object manager, and a communication manager. A central manager, which may be provided on another server, interacts with virtual machine servers in a cluster to facilitate sharing so that object state is maintained consistently on all virtual machines. The central manager includes an object manager, a lock manager, transaction manager, communication manager, and a persistence manager.
In one aspect, the technology provides a clustering server which provides data sharing among virtual machines in a cluster. A virtual machine identifies "managed" objects of an instance of an application running at the virtual machine. The managed objects are objects for which state information is to be replicated at the other virtual machines in the cluster on which other instances of the application are running. Operations performed by an instance of one application which affect the state of managed objects are detected and distributed. These operations may include for example method calls and field set operations. The virtual machine then communicates information to the central manager for use in replicating the state information at the other virtual machines. For example, a managed object may be identified by an object graph which includes the managed object as a root object. All objects which can be reached by reference from the root object also become part of the object graph and are thereby also managed. In this case, the state information of the virtual machine can be replicated at the other virtual machine by updating object graphs at the other virtual machines so they are replicas of the object graph of the virtual machine on which object state has changed. In this way, object state is maintained consistently among all of the virtual machines.
In one aspect, the invention includes a computer-implemented method for maintaining consistent object states at different virtual machines. The method includes receiving managed object state information from a first virtual machine including a first instance of an application; creating a representation of each of the managed objects; and responsive to the received information, communicating state information to at least a second virtual machine on which a second instance of the application is running to replicate the state information at the second virtual machine.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The technology described herein includes a set of integrated components that provides a common virtual machine capability for application programs running on distributed systems each having its own local virtual machine. The components discussed herein allow transient data—data actually stored in memory in a virtual machine as part of in-memory object state—to be shared across various virtual machines. In a unique aspect, object state is shared through a series of shared operations, either logical or physical operations, which are detected and distributed as a series of transactions in order to replicate the current state of objects at any of the virtual machines throughout a cluster.
The technology will be described with respect to its application in conjunction with Java applications and Java Virtual Machines. However, it should be recognized that the inventive concepts have broader applicability to other virtual machine and development environments. Moreover, the managed objects utilized on various virtual machines need not be shared by the same application. Finally, as explained herein, respective virtual machines need not operate concurrently.
This allows various features to be provided by the technology, include sharing of object state between virtual machines, flexible locking which is configurable at run-time, distributed method invocation and distributed wait-and-notify. Benefits include distribution of data among the virtual machines without the need to maintain state in a database, transparent recovery from application instance failures, clustering as an API-free infrastructure service, reduced development, testing, and maintenance costs, faster application development and scale-out, and fine-grained operations performance visibility and control. With the data sharing functionality provided, there is no API for the application developer to learn, apply, test, and maintain since the data sharing agents/libraries provide this transparency. Lower system life-cycle costs are another benefit, since organizations using the system need not spend time writing code in order to provide clustering capabilities. The system accomplishes this as an infrastructure software component that provides clustering as a service based on user-defined configuration settings which can be changed at production-time. This allows an application to adapt its reliability, availability and scalability characteristics to changing user demands without the need for new development.
In many cases, the data sharing functionality enhances performance. For instance, in one approach, when a shared object is updated, only the field-level changes are sent to the different virtual machines, and only those virtual machines with that object currently in memory are supplied with the update in real time. In another approach, the logical operations necessary to create a current object state are shared between virtual machines. These techniques significantly reduce the amount of data movement, and improve all-around performance of a fully clustered application. Moreover, the data sharing functionality provides this inter-virtual machine communication capability in a scalable manner that cannot be matched by peer-to-peer products.
As used herein each server or processing system includes, for example, one or more processors capable of executing instructions provided on readable media to perform the methods and tasks described herein. The processing system may include a volatile memory, a mass storage device or other non-volatile memory, a portable storage device, one or more communications or network interfaces and various I/O devices. The above described processing system hardware architecture is just one suitable example of a processing system suitable for implementing the present technology.
The servers 110, 120 and 130 each include a separate instance of an application, for example, application instance "A" 111, application instance "B" 121 and application instance "C" 131. Further, each server includes a virtual machine on which the application code executes, namely virtual machine "A" 112, virtual machine "B" 122 and virtual machine "C" 132. For example, each virtual machine may be a Java Virtual Machine (JVM) which executes byte code of an application. In one embodiment, the applications are the same application with different instances; in another embodiment, the applications call the same instances of the same classes of objects in their respective application code.
Each instance of the application runs locally on each application server and interacts with each virtual machine locally. Objects used by the application are created and maintained by the respective virtual machines on each server. In accordance with the invention, the application code for each of the applications need not provide for the clustering operations described herein. In essence, the application is prepared to run on a single virtual machine and extended to the cluster by the technology discussed herein. In this regard, a series of managed objects, which include a local instance of application object on each server, are identified and clustered by the technology.
A data sharing agent/library 113, 123 and 133 is provided on each respective server to provide functionality for sharing managed objects among the servers, as described in greater detail below. Files stored at the data sharing agent/library are loaded into the associated virtual machine upon start up to modify the application code when compiled into bytecode to provide the data sharing functionality. In particular, the data sharing agents 113, 123 and 133 are responsible for performing bytecode manipulation to implement clustered object management in each local virtual machine 112, 122 and 132. Each may include a lock manager that deals with gaining access to objects under locks, a transaction manager that creates a transaction log as described below, and an object manager. A communication manager may also be provided to enables the virtual machines to communicate with the central manager. The communication manager may include IP address and port information of the central manager.
Each server 110, 120, 130 may also include a conventional operating system and memory for storage of data, such as data used by threads of the application instances.
A central manager 140 is provided to facilitate data sharing among the virtual machines and, in particular, between the virtual machines on which the application instances run. The central manager 140 in conjunction with the data sharing agent/library 113, 123 and 133, acts as a "clustering server" for the applications 111, 121, 131. In essence, each application 111, 121, 131 sees one virtual machine, but with each application instance seeing changes to objects made by other application instances in the cluster. The central manager 140 includes a data sharing application 141 running in an operating system on the manager. The manager may be a separate physical server or may operate on a server with one of the virtual machines. The central manager 140 has the ability to communicate with each of the servers 110, 120 and 130 to share object state information.
The data sharing application 141 works in concert with the data sharing agent/libraries 113, 123 and 133 to distribute shared objects amongst the cluster systems 110, 120, 130. The data sharing application 141 can include a lock manager, transaction manager, communication manager, and a persistence manager. The persistence manager is able to persist object state information to a CM object representation store. The lock manager manages access to distributed locks between the various virtual machines. The transaction manager deals with moving data between members of the cluster in coherent terms. The object manager deals with keeping track of which virtual machines have what objects and what version of the object. A communication manager which enables the central manager to communicate with the virtual machines.
The object representation store 144 includes a record of the managed object states in accordance with the methods discussed herein. Because of the persistence of managed objects by the representation, each of the servers 110, 120, 130 need not operate concurrently.
Advantageously, the central manager 140 and data sharing agent/libraries are implemented by a set of infrastructure software (which may be commonly distributed) that can be installed on suitable processing system hardware.
Subsequent to the installation of agents 113, 123 and 133, virtual machines 112, 122 and 132 are essentially clients of the central manager. As such, virtual machines may be referred to herein as clients. It should be understood that
A management console 150 provides a graphical user interface which allows an operator to configure and monitor the central manager 140. Optionally, the operator may define configuration files which are provided to the data sharing agent/library to specify which objects should be shared. This configuration data allows various managed objects to be included as managed objects or excluded as managed objects on each of the virtual machines in a cluster. In essence, this provides a form of drop-in/drop-out functionality for the managed objects. The management console can also be used to monitor: a) a current count of unique managed object instances for each client, on a per-class basis; b) a creation rate of managed objects, where both global and per-client counts are provided; c) a rate at which objects are flushed from the clients to the central manager, on a per client basis; d) a rate at which objects are requested from the central manager by a client, on a per client basis; e) a rate at which objects are written to a persistent object store by the central manager; f) a rate at which objects are requested from the persistent object store by the central manager; g) a view of all currently managed roots and fields; h) a list of locks with one or more pending lock or upgrade requests; i) a list of application process threads currently waiting due to contended locks; j) an on-demand display of locks which are currently part of process deadlocks; k) elapsed processing time and number of objects collected by the central manager garbage collection process; and l) a rate at which transactions are committed to the central manager, whether both global and per-client counts are provided.
In one approach, application code at the server (110, 120, 130) is instrumented using files stored by the data sharing agent/libraries when the application code is loaded into the virtual machine. Where a bootstrap loader 205 is utilized, a custom "boot.jar" file may be used to replace the class definitions in the system dependent runtime .jar file. Where the virtual machine technology 210 does not implement a bootstrap class loader 205, this technique is not required. Other class loaders 224 are instrumented to allow the data sharing agent/library files to introduce the data sharing functionality into the application classes. Class loaders enable the virtual machine 210 on any respective server to load classes without knowing anything about the underlying file system semantics. Similarly, the class loader 224 allows the application 222 to dynamically load classes. The data sharing agent/libraries can inspect and, if activated, intercept API calls made by the application 222. The scope of interception can be at a byte code level, in which case field updates, method calls, synchronization calls, and wait/notify calls, for instance, are visible and controllable at runtime. When alternative facilities, for example HotSwap or JVMTI, are provided by the virtual machine, the data sharing agent/libraries can introduce the data sharing functionality to application classes through these mechanisms. This technique allows the data sharing agent/libraries to delay and optimize the introduced data sharing functionality.
Note that the application source code remains unchanged, and in one implementation, no stored byte code is changed such that were one to decide not to run the clustering server, one can restart the application without enabling the byte code manipulation. As discussed more fully below, during this process, object classes specified as shared are identified and instrumentation added to allow server locking and logical change tracking.
Due to the instrumentation of bytecode at the virtual machine level, another aspect of "drop-in/drop-out" capability is provided. That is, the data sharing functionality which is provided by the instrumentation can be easily activated or deactivated by a system operator at application runtime. This drop-in/drop-out capability further allows the data sharing functionality to be provided for existing applications without modifying the application code to conform to an API, or providing any such API. The developer can write an application for a single virtual machine and configure the application to be transparently shared across multiple virtual machines. All that is required is the installation of the data sharing agent/libraries and the proper configuration of opt-in parameters via the management console. The drop-in/drop-out capability also allows rapid assessment of the degree to which the data sharing functionality can benefit a given application, what-if analysis of various opt-in sets, and the ability to switch the data sharing functionality on and off at runtime. The drop-in/drop-out capability also eliminates the need to use custom-developed or vendor framework clustering and memory sharing in new applications since these needs can be handled with no need for explicit code.
This data sharing functionality may alternatively be implemented in the bytecode interpreter natively. That is, while developers normally do not have access to the bytecode interpreter, virtual machine providers who do have access to the bytecode interpreter may build the same functionality provided by instrumentation of the bytecode at the classloader level directly into the virtual machine instead.
In this step, the byte code instrumentation adds functionality to each managed class transparently. Exemplary pseudocode representations of this functionality include a function lockmanager.getlock( ), a transactionmanager.starttransaction( ) and a transactionmanager.commitTransaction( ) and lockmanager.releaseLock( ). As will be explained below, the getlock and releaseLock functions request, respectively, a lock from the central manager for the cluster-wide managed object via the lock manager process, and a lock release on the managed object from the central manager. The transactionmanager.starttransaction and transactionmanager.commitTransaction functions are used to generate transactions which communicate changes to the central manager. These functions surround the application code, as described below.
At block 310, an object graph of each of the identified root objects is navigated to identify the objects that can be reached from the root object. For example, an object is reachable by the root object if there is a field assignment of an object reference into one of the root's field values at runtime. At block 315, the objects in the object graph are identified as managed objects, such as by flagging the objects. Thus, the root object and the objects reachable from the root object become managed objects. Optionally, the operator can use the management console to selectively exclude objects which are reachable from a root object from being managed by declaring a field to be transient.
In one aspect, the manager allows specification of root objects to manage all objects accessible by the root. An object is reachable by the root object if it is part of the object's reference graph, such as, for example, where there is a field assignment of an object reference into one of the root's field values at runtime.
An object graph includes a root object and objects that are reachable from the root object. A root object can be a long-lived object, such as a cache implemented using native Java collections, a servlet session, or a hash map, an example of which is provided by the Java class HashMap. For example, the operator can configure managed objects using a configuration file in a known format, such as XML, or alternatively use the management console to identify the managed objects. Moreover, note that not all objects in an application need be managed. Only a subset of all objects used by an application need to be identified as managed. A managed object is a distributed object whose state is maintained consistently at the different virtual machines in a cluster of virtual machines. Generally, it is desirable to manage objects that represent pure state information, while avoiding replicating objects that refer to operating system resources. For example, business objects such as customer records might make good managed objects.
For example, an XML configuration file at the data sharing agents/libraries may modify values of a "<root>" element. The operator specifies the fully qualified field, and a name to associate with the field. To illustrate, the following configuration sets up two objects for sharing—"exampleField1" and "exampleField2", which are members of the "ExampleClass1" and "MyClass2" classes, respectively:
Alternatively, roots can be given a common "name" even though they may be two differing fully qualified field names. In this case, the two or more root fields that share the common name will refer to the same object instance. Hence, one can, in two different classes, bind the same root to different variables. In terms of the example, even though there are two different fields in different classes, even though they are different fields, if they share a common name, they will be the same set of objects.
The object manager in the client can dynamically prune in-memory versions of a managed object graph so that only portions of the managed graph need be stored in the client virtual machine's memory at a time. This allows arbitrarily large shared object graphs to be fit into a constrained memory footprint in the client virtual machines. Pruned segments of the object graph can be faulted in from the server dynamically as needed as code on a virtual machine traverses the managed graph and follows a reference to an object that has been pruned. This process happens automatically and transparently to the user code. As this happens, the permanent representation of the managed object graph is unaltered in the central manager.
Returning to
At block 330, information identifying the operations, such as the method calls and field set operations, and the central manager level (or global) unique identifier of the object or objects involved, is communicated from the virtual machine to the central manager and, at block 335, the central manager uses the information to update a representation of the managed objects' states locally and at other virtual machines.
The central manager may assign global identifiers to the managed objects so that it can recognize any managed object in the cluster. Conventionally, only locally specific, non-deterministic identifiers are assigned to objects by the virtual machines. In accordance with the technology herein, when a new managed object is created on a local virtual machine, a global unique identifier is assigned to the object by the virtual machine on which the object is created. A group of central manager level unique identifiers is provided by the central manager to each virtual machine.
Updates to the fields of a managed object are tracked at a fine grained level of granularity and pushed to other virtual machines via the central manager. By joining a root graph, an object is flagged as managed and its state is kept up-to-date across a cluster of servers.
In one case, transactions can be provided on both method and Java synchronization boundaries, where a transaction is a set of changes to managed objects made between defined transaction boundaries. Transactions are associated with, and protected by, zero or more locks. Transactions and locks function as a multi-virtual machine extension of standard Java synchronization and the Java memory model. Java synchronization provides exclusive thread access to sections of code on monitor/lock enter, and flushes local changes to main memory on monitor exit. In a cluster, locks provide a user-defined, cluster-wide access policy to sections of code, and local changes are flushed to the central manager at the close of a transaction. In this way, threads in a cluster of multiple virtual machines can interact in the same way that they do in a single virtual machine.
This is illustrated by
In this example, a users object references a map called mycache. Once one establishes a reference that the cache is managed, then the entire sub-graph of an object is managed. That is if mycache is managed, as a root, everything it points to is also managed Note that Java primitives may also be assigned object IDs also. Once a managed object has a reference to an unmanaged object, it makes everything that it references become managed.
As noted above in
Step 325 is performed by recording, for example, the method calls or field set operations that the application code has performed. Instead of keeping track of the actual object references, the transaction log keeps track of the actions the application has done. Every time a central manager need to create the object in a new VM or to make changes to it, it can replay this log. For each action, such as when a new object is created or a function (such as a put call) is performed, this logical action is recorded and the physical steps written into a transaction. Any new objects and their data is now recorded in the log.
These transactions are stored in one format in the memory in the virtual machine, then transmitted to the central manager (in, for example, a serialized format) in the message in the communications layer and deserialized at the central manager.
At step 330, VM1 updates the central manager. The updating may occur from time to time at various points in the execution of the application code. For example, the updating may occur after the application updates one or more managed objects under a lock, as discussed above. As noted briefly above, the instrumentation added to the application code may include a transactionmanager.committransaction( ) which takes the log built up in the transaction through this whole process, and communicates it to the central manager. The shipping may occur immediately or in a grouped set of transactions, such as in a batch job.
To perform the update, VM1 communicates a log, VMLog, to the central manager. VM1 may delete the log and start a new log when the central manager confirms receipt of the log. Any type of network communication technique may be used. As mentioned, the data sharing agent/library at each virtual machine may include functionality for communicating with the central manager.
At block 630, the central manager processes the transactions stored in the VMLog to update a local representation of the states of the managed objects. Essentially, the operations such as method calls, with associated field values, which were performed at VM1, are stored in a data structure on the central manager.
A description of each object is provided on the central manager. This description includes meta data defining the object's class, its fields and the field values. For a physical object, for example a class "myclass" with four fields, the server description includes the server class and IDs for each field. For example, a physical object includes the name of the class, the name of the class loader, fieldname, field value pairs for literal fields, field name and referenced object ID pairs for reference fields, object version, and possibly other information. For logically managed objects, one needs to know what to do with changes which may have occurred. A description of a logically managed object in includes, for example, where the logically managed object is a map, the contents of which may be a set of keys, collection of values, or set of key-value mappings. The order of a map is defined as the order in which the iterators on the map's collection views return their elements. For this example of a logically managed object, a representation of the map is kept on the central manager. The representation relates the object ID or literal keys to the corresponding object ID or literal values. In addition, a logical action (such as a put) is assigned a function ID which is interpreted by the central manager allowing the central manger to create the appropriate mapping of keys to values. In the case of other logically-managed classes, such as a list, examples of logical actions are add and remove; for a map, actions includes puts and gets; any number of logically managed actions may be stored in this manner. The central manager's representation is not another instance of each managed object, but merely a representation of that object.
Each logical action performed on a logically managed object is identified and the data associated with the logical action provided to the central manager to update its representation. These logical actions are passed to any other virtual machine in the cluster that currently has said logically-managed object in its memory so they may be replayed against its local instance of said managed object.
At block 635, the central manager updates the other virtual machines in the cluster so that the state of the managed objects at VM1 is replicated at the other virtual machines. As noted above, depending on whether the update is of a physically managed object or a logically managed object, the transaction may have a slightly different format. In addition, there are two different scenarios for an update depending on whether or not the update to the other virtual machines is an initial update (decision block 640).
An initial update occurs when the central manager first updates a virtual machine, in which case it is necessary to convey the current state of the managed objects to the virtual machine. This may occur after application startup or after a new virtual machine joins the cluster. In one approach, the central manager can store each of the logs received from VM1 (or any of a number of VMs) and provide them to the other virtual machines to be played. However, this approach is inefficient as many operations may change the same managed objects repeatedly. Since only the most current state of a managed object is relevant, and not the previous states it traversed to reach the current state, it is more efficient for the central manager to generate a log of operations (central manager log) from its representation of object state (block 645). This approach is more efficient since only the operations which are necessary to reach the current object state are generated. At block 650, the central manager communicates the central manager log to the other virtual machines and, at block 655, the virtual machines play the central manager log to update their local representations of object state. The operations in the central manager log, such as method calls and field set operations with associated values, are performed at the other virtual machines so that the state of the managed objects at the central manager, and at VM1, is replicated at the other virtual machines. An object graph at the other virtual machines is thereby updated so that it is a replica of the object graph at the central manager and at VM1.
If an initial update of a virtual machine has already been performed, then the subsequent updates can be incremental updates. In this case, the central manager conveys the virtual machine log from VM1 to the other virtual machines (block 660), and the other virtual machines play the virtual machine log to update their local representations of object state (block 665). Again, the object graphs at the other virtual machines are thereby updated so that they are a replica of the object graph at the central manager and at VM1. The updating of the other virtual machines by the central manager may occur from time to time. For example, the central manager may update the other virtual machines when it receives an update from VM1.
Note that the process shown in
Initial and incremental updates are illustrated further, as follows, in
By sharing object data at a field level of granularity, it is possible to share changes to object state at a fine grained level. That is, changes to specific fields of managed objects can be shared among virtual machines without sending unnecessary information regarding fields of managed objects which have not changed, or fields of unmanaged objects. This approach minimizes the amount of information which needs to be communicated between the central manager and the virtual machines. For example, referring to the "Address" object 540 in
When an operation on a managed object occurs in the application (as in step 320 previously described), transactions are created at step 902 in accordance with the foregoing description of steps 1315, 1320 and 1325. The information transmitted will depend on whether the object is a physically managed object or a logically managed object (step 904). If the object is a physically managed object, at block 915, field level changes to the managed objects are provided in the transaction. That is, the changes are detected at a field level of granularity. This may include, e.g., detecting field level data affected by an application function. At block 920, a central manager uses the field level data to update its local representation of object state. The information provided at step 915 may include for a physical object, the name of the class, the name of the class loader, fieldname and field value pairs for literal fields, field name and referenced object ID pairs for reference fields, object version, and possibly other information, as discussed above.
At block 925, to perform an update of any other VM, the central manager communicates the field level data to the other virtual machines in the cluster and, at block 930, the other virtual machines use field level data to update respective local instances of the managed objects.
Similarly, if the transactions affect logically managed objects, the transactions include logical operations at step 935. At block 940, a central manager uses the method calls and other logical operations to update its local representation of object state. At block 945, to perform an update of any other VM, the central manager communicates the logical operations to the other virtual machines in the cluster and, at block 950, the other virtual machines replay those logical operations against their respective instances of the managed objects to update the state of those managed objects.
As noted above, when application operations occur at step 320 accessing or affecting a managed object, those operations are detected at step 325. Each virtual machine (in this example VM1) is responsible for updating and maintaining its own local representation of object state at step 610. VM1 maintains a local representation of the states of the objects which are instantiated by the application, including managed and non-managed objects. The VM updates any change to a local instance of a managed object at step 1015.
Step 325 is performed by recording, for example, the method calls or field set operations that the application code has performed. Instead of keeping track of the actual object references, the transaction log keeps track of the actions the application has done. For each action, at block 1025, data identifying the operations of a changed object is included with the transaction. That is, for each transaction, an object ID is generated at the client and, as noted above, is provided as part of the field data for a physically managed object, as well as the operations data for a logically managed object. Object references are thus maintained in the local representation at the central manger and at any other VM using the CM log to update its local representation of the object. At block 1030, the central manager is updated. To perform the update, VM1 communicates data identifying the object and the logical operations to the central manager. At block 1035, the central manager updates its local representation of managed objects using the object ID and transaction ID data. At block 1040, the central manager communicates data identifying the operations to the other virtual machines and, at block 1045, the other virtual machines update existing instances of the changed objects without creating new instances of the objects. With this approach, object identity is maintained across the virtual machines.
The central manager also provides various cluster wide locking functionality. In one embodiment, both named manual locks (named locks) and automatic locks (auto locks) are provided. Clustered locks can span an arbitrary number of VMs. For automatic locking, the CM globally locks any point where the application code uses, for example, the Java "synchronized" keyword, to provide distributed locking for applications where "synchronized" is already in use or where the application is multi-thread safe. Named locks can be used with help from developers for applications that were never designed to be distributed and multi-threaded. Named locks specify which blocks of code in any application should be locked globally.
Both auto locks and named locks are available in two different modes, clustered locks and greedy locks. With clustered locks, the virtual machine obtains a lock explicitly from the central manager each time a lock is needed.
At block 320 the application in the course of performing operations will request a lock on a managed object A virtual machine may request a lock when it encounters a block of code which uses the Java key word "synchronized", as mentioned previously. Alternatively, the operator may use the management console to designate a block of code of an application which does not use the keyword "synchronized" as a method which invokes a request for the lock.
In one embodiment, both named manual locks and automatic locks, are implemented. Administrators can use automatic locks, which globally lock any point where the application code uses, for example, the Java "synchronized" keyword, to provide distributed locking for applications where "synchronized" is already in use or where the application is multi-thread safe. Named locks can be used with help from developers for applications that were never designed to be distributed and multi-threaded. With named locks, users can specify which blocks of code in an application should be locked globally.
At block 1115, VM1 sends a request for a lock to the central manager. At block 1120, the central manager accesses its records to determine if the lock on the object is currently available. For example, the central manager may maintain a record listing object identifiers and associated lock status, indicating whether there is a lock on an object and, if there is a lock, which thread in which virtual machine has the lock, and the type of lock, e.g., read, write or concurrent. A read lock allows all instances of the application on the different virtual machines to have concurrent read access but not write access to managed objects within the scope of the given lock. A write lock allows one thread on one virtual machine to have read and write access to managed objects within the scope of the given lock, but prevents any other thread in any other virtual machine from acquiring the given lock. A concurrent lock allows multiple threads on multiple virtual machines to make changes to managed objects at the same time. This lock maintains a stable view within the transaction that the lock protects but allows write-write conflicts between threads in the same or other virtual machines. Concurrent locks should be used when performance is more important then the possibility of write-write conflicts. In the case of a write-write conflict, the last writer wins.
At decision block 1125, if the lock is not available, the central manager waits until the lock becomes available. When the lock is available, the central manager grants the lock to the requesting virtual machine, at block 1135, and updates its records accordingly. If applicable, at block 1140, the central manager blocks any other thread in the same or other virtual machines from taking control of the lock. At block 1145, the virtual machine may perform any operation under the lock locally without CM interaction.
After using the lock, the virtual machine informs the central manager that it is releasing it, at block 1150. At block 1155, the central manager updates its records accordingly, and grants the lock to the next thread in contention for that lock in any connected virtual machine, if any. That is, the lock is granted to any other thread in any virtual machine that is blocked in contention for the lock.
In another alternative, the lock is a "greedy" lock, in which case the virtual machine holds the lock so that threads local to that virtual machine may acquire and release the lock repeatedly (at step 1145) without communicating with the central manager until the central manager commands it to release the lock. With a greedy lock, VM1 holds the lock not only for the duration of one synchronized block, but until the lock is recalled by the central manager, such as if another virtual machine requests the lock from the central manager.
The following pseudo-code provides a further illustration of the concepts described herein. Assume the following pseudo-code represents application code which has been instrumented in accordance with the discussion of step 305. In this example, a new thread is adding a new object and the agent will traverse the graph of the person object and make all the objects it refers to managed and give them all object IDs. A record of these new objects is placed into the transaction log which will be forwarded to the central manager. Note that each VM gets a batch of central manager level object IDs ahead of time so that it can assign them to the objects. For example, each VM may get any number of new object IDs that it can assign locally at will. If it runs out of object IDs, it can request additional IDs from the central manager. Also note that the VM's internal object ID does not affect the central manager or the central manager level Object ID. The code below may be operated on by a thread on any virtual machine.
First, assume that at VM1 there are two threads active both asking for a lock on the object "myCache". In this example, the object myCache has been identified as a managed object. A first thread will be granted the lock by virtual machine VM1. Next, the data sharing agent indicates to the central manager that there is a thread on VM1 that has requested a lock on myCache. The agent requests a lock from the server. If no other virtual machine has the lock, the central manager will grant the lock to the VM.
At this point, the application code at VM1 is able to move on. In the virtual machine, the agent starts a transaction for this thread. The agent will now keep track of logical actions and field changes to managed objects performed by thread one. This occurs whenever a thread obtains a lock on a managed object.
Once this first thread has received a lock and started its transaction, now it is able to execute the operations in the protected block of code as originally defined by the application code. Suppose, for example, a second VM with another thread trying to execute the same block of code protected by the same lock on a different virtual machine. There are now two threads locally that are synchronized by VM1, and a third thread on VM2 trying to access the same object. The native lock manager of VM2 will allow this lock, but when the function "getLock" is performed on VM2, the central manager will not grant VM2 the lock because it is already held by thread one in VM1.
Threads two and three are blocked trying to get a lock. Thread two is on the same VM as thread one, so it is blocked trying to get the VM1 object monitor from the native lock manager of VM1. Thread three has been given the local monitor on VM2 but is blocked trying to get the clustered lock from the central manager.
The application code can then perform the put operation (in this example) on the object once the lock is granted. Once this is completed, the transactionmanager.committransaction( ) takes the log built up in the transaction and ships it to the central manager. Next, since thread one is finished with the lock, the lockManager.releaseLock(myCache) releases the clustered lock. Thread one exits the protected block of code and has now completed its work.
Once thread one in VM1 has released the local lock, the native lock manager in VM1 allows thread two to obtain the local lock. If the central manager grants thread two the clustered lock, thread two executes the same block of code against another user object. While that is happening, thread three at VM2 is still blocked in contention for the clustered lock from the server, even though it has been granted the local lock by the native lock manager in VM2. Thread three remains blocked until thread two completes its execution of the protected block of code and releases the lock. At such time, the central manager awards the clustered lock to thread three in VM2. Because thread three is in a separate VM than threads one and two, the transactions created by threads one and two must be applied, in order, at VM2 to bring the changed managed objects up to date before thread three is allowed to execute the protected block of code. Once the transactions created by VM1 under the scope of the clustered lock have been applied in VM2, thread three is allowed to execute the protected block of code. When thread three has completed the protected block of code, the transaction it created is committed and the clustered lock is released by thread three. The clustered lock returns to its uncontended state.
For example, if a thread currently holds the lock on an object, it may call "object.wait( )" which causes the calling thread to release that object's lock and pause execution. Another thread may then acquire the lock on that object. It may then call the Java method "object.notify( )" which will notify a single thread waiting on that object. It may also call the Java method "object.notifyAll( )" which will notify all threads waiting on that object. Waiting threads that are notified in this way resume execution and go back into active contention for that object's lock. While this is satisfactory in a single-virtual machine environment, a technique is needed for signaling threads on different virtual machines to coordinate the pausing and resuming of thread execution. A technique is needed for extending existing thread signaling mechanisms such as Java's "object.wait( )" and "object.notify( )" methods to apply to all threads in all virtual machines in the cluster as they do to threads in the same virtual machine. See, for example, http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.8 An example of such a technique follows.
In a unique aspect of the technology, the native thread signaling utilities of a virtual machine are extended to the cluster. These can include, in a Java context, synchronization (grabbing the lock in the first place), wait and notify, the Thread.join( ) method, and the like. In other virtual machine contexts, other thread signaling technologies may be extended.
Once the notification is sent, step 1320 is true and the first thread will then request access to a lock at step 1330. Any other threads which were waiting on the notification will likewise resume execution and request access to the lock at step 1335. At step 1340, the central manager will perform lock management in accordance with the foregoing discussions.
Note that while example implementations are discussed in which virtual machines run on servers, which is a suitable approach for storing large amounts of data for a web-based application for instance, any type of computing device may be used, including personal computers, minicomputers, mainframes, handheld computing devices, mobile computing devices, and so forth. Typically, these computing devices will include one or more processors in communication with one or more processor readable storage devices, communication interfaces, peripheral devices, and so forth. Examples of storage devices include RAM, ROM, hard disk drives, floppy disk drives, CD ROMS, DVDs, flash memory, and so forth. Examples of peripherals include printers, monitors, keyboards, pointing devices, and so forth. Examples of communication interfaces include network cards, modems, wireless transmitters/receivers, and so forth. In some embodiments, all or part of the functionality is implemented in software, including firmware and/or micro code, that is stored on one or more processor readable storage devices and is used to program one or more processors to achieve the functionality described herein.
The foregoing detailed description of the technology herein has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the technology and its practical application to thereby enable others skilled in the art to best utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
Property Details
Condo, 2 Bedrooms, 2 Baths, 6 Sleeps
Situated on the 21st floor of the Setai Resort,this white decorated apartment offers views of the ocean, South Beach and Miami skyline from floor to ceiling windows. Two queen sized beds in the master bedroom and a king sized bed in the second bedroom. Wifi & Cable. Beach, Pool, Gym, Spa, Valet Parking and Restaurants. Sleeps 6.
*The rates advertised are up to October 15th, 2014. Please contact us for rates after October 15th, 2014*
About the Owner
0 Reviews
Be the first to review this listing!
Rental rates
Rates vary depending on the season.
There is a 3-7 night minimum depending on the time of year.
- 12
- Available
- 12
- Unavailable
- 12
- Today
Property Type
- condo
- Luxury
- Romantic
- Air Conditioning
- Internet
- children welcome
- pets considered
Location Type
- Beach View
Sports & Adventure Activities
- golf
- 2 Bathrooms
- Bathroom 1
- Bathroom 2
- 2 Bedrooms, Sleeps 6
- Bedroom 1
- Bedroom 2
- The Setai has a beautiful spa, gym, 3 separate pools with different temperatures. 2 restaurants (The Grill, and the restaurant at the Setai) and a pool bar. Valet is included in the rent. 24 hours room service, full concierge service, doorman, bellman and security are available 24hrs a day.

subset: commoncrawl


text:
To embed, copy and paste the code into your website or blog:
Today, the U.S. Supreme Court issued a unanimous opinion (by Chief Justice Roberts) in Filarksy v. Delia, No. 10-1018, holding that a private lawyer who was retained by a local government is entitled to assert qualified immunity. Along with our colleagues at the ABA Section of State and Local Government Law, we filed an amicus brief in the case on behalf of the American Bar Association supporting the lawyer's claim to immunity.
The issue in the case involves the immunities that lawyers may be entitled to claim in civil rights actions under 42 U.S.C. § 1983. The specific issue before the Court was whether Mr. Filarsky, a private lawyer retained by the City of Rialto, California to conduct a portion of the city's internal investigation of a city employee, was entitled to claim the same qualified immunity that is generally available to government employees acting in good faith who are defendants in 1983 actions. The Ninth Circuit concluded he could not avail himself of that defense, merely because he was not a government "employee." The Supreme Court unanimously reversed.
Firefox recommends the PDF Plugin for Mac OS X for viewing PDF documents in your browser.
We can also show you Legal Updates using the Google Viewer; however, you will need to be logged into Google Docs to view them.
Please choose one of the above to proceed!
LOADING PDF: If there are any problems, click here to download the file.
Reference Info:Decision | Federal, U.S. Supreme Court | United States
DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.
© Robert Thomas, Damon Key Leong Kupchak Hastert
Read fresh new writing on compliance, cybersecurity, Dodd-Frank, whistleblowers, social media, hiring & firing, patent reform, the NLRB, Obamacare, the SEC…
…or whatever matters the most to you. Follow authors, firms, and topics on JD Supra.
Create your news brief now - it's free and easy »
Robert H. Thomas focuses on issues involving appeals, regulatory takings, eminent domain, water...
View Profile »
See more »
Sign up for your custom alerts now, using LinkedIn ›
Back to Top
Copyright ©


text:
Brazil and Russia's Engagement in Global Health
FP: Brazil's Public Option
Eduardo Gomez writes that as President Obama pushes to pass healthcare reform in the United States, "he would do well to examine the praiseworthy successes -- and the worrying failures -- of a decades-old universal system in the region's second-largest democracy."
Brazil and Russia's Engagement in Global Health (Transcript)
This session was a meeting of the Emerging Powers in Global Health Governance roundtable series.
Terms of Use: I understand that I may access this audio and/or video file solely for my personal use. Any other use of the file and its content, including display, distribution, reproduction, or alteration in any form for any purpose, whether commercial, non commercial, educational, or promotional, is expressly prohibited without the written permission of the copyright owner, the Council on Foreign Relations. For more information, write firstname.lastname@example.com.


text:
New day. New Daily Deals. Get them before they are gone!
Can't find what you're looking for? Shop all ink and toner cartridges by brand
New Customer ? Start Here.
New day. New Daily Deals. Get them before they are gone!
Item: STX61259B01C Model: 61259B01C
Storex Single-drawer mobile filing cabinet in black color accommodates letter or files and measures 12.75" x 14.75" x 18.25". Cabinet features removable casters that allows being stacked on top of drawer for added storage capacity.
|Color Family
|Paper Size
|File Storage Lid Type
|File Storage Material
|File Storage Strength Rating
|Standard Strength (up to 500 lb.)
This Web site is intended for use by US residents only. See International Sites. See our delivery policy for full details. Copyright 1998-2014, Staples, Inc., All Rights Reserved.


text:
Email Us
Research Services
** Upcoming Citation Workshops **
Does the idea of doing your bibliography at the end of a paper stress you out? Need help with parenthetical citations or footnotes while you are writing? Check out the workshops below:
- Zotero: Introduction to collecting, managing, and citing your research sources
- The RIGHT way to CITE: Cite and manage your resources as you go
Chat is offline. Use this email form and we will be in touch.
* indicates required field


text:
Dawn Richards is reimaging the comic book that her former singing group was named for.
Dawn has signed a deal with eigoMANGA to release an adaptation of her Danity Kane comic book. Originally the series was about the music scene and it featured a more American art style.
Now, with the help of writer Natasha McGough, Dawn is taking her creation into a whole new direction. Danity Kane's story will center on a young and powerful, albeit naive, alien who is sent to Earth to free her people. But if the panels we've seen are any indication, music will still be involved in the plot somehow.
You'll have to wait a few more weeks to see what Dawn has reimagined for her heroine. Danity Kane, which will be released as a manga (aka Japanese-style graphic novel), is slated to hit shelves this spring. In the meantime, you can take a peek at samples of the comic and character design.
— Sonya Eskridge
Here's more:
Dirty Money Crew shows 'Love'
Diddy and Dawn working on Danity Kane do-over?
Danity Kane returns for season finale


text:
Resolution: standard / high
Figure 3.
Immunohistochemical comparison of the reactivity of 18-9 MAb (A) versus control MAb (B) in parallel sections of the gastric antrum. In both panels, the highest immunoreactivity is located in the surface epithelial cells. Control MAb shows slightly higher staining in the glands (GL) and lamina propria (asterisk).
Parkkila et al. BMC Clinical Pathology 2008 8:2 doi:10.1186/1472-6890-8-2


text:
Evaluation of Scrotal Masses
FREE PREVIEW. AAFP members and paid subscribers: Log in to get free access. All others: Purchase online access.
FREE PREVIEW. Purchase online access to read the full version of this article.
Am Fam Physician. 2014 May 1;89(9):723-727.
This clinical content conforms to AAFP criteria for continuing medical education (CME). See CME Quiz Questions.
Patient information: See related handout on scrotal masses, written by the authors of this article.
Author disclosure: No relevant financial affiliations.
Scrotal masses are caused by a variety of disorders, ranging from benign conditions to those requiring emergent surgical intervention. Painful scrotal masses require urgent evaluation. Characteristics that suggest testicular torsion include rapid symptom onset, nausea and vomiting, high position of the testicle, and abnormal cremasteric reflex. Doppler ultrasonography or surgical exploration is required to confirm the diagnosis. Surgical repair must occur within six hours of symptom onset to reliably salvage the testicle. Epididymitis/orchitis have a slower onset and are associated with a C-reactive protein level greater than 24 mg per L (228.6 nmol per L) and increased blood flow on ultrasonography. Acute onset of pain with near normal physical examination and ultrasound findings is consistent with torsion of the testicular appendage. Testicular malignancies cause pain in 15% of cases. If ultrasonography shows an intratesticular mass, timely urology referral is indicated. Inguinal hernias are palpated separate to the testicle and can cause pain. Emergent surgery is indicated for a strangulated hernia. Hydrocele, varicocele, and scrotal skin lesions may be managed in nonurgent settings. A biopsy should be performed to rule out cancer in patients with scrotal skin lesions that are erosive, vascular, hyperkeratotic, or nonhealing, or that change color or have irregular borders.
Scrotal masses are a common presentation in primary care, and a painful scrotum accounts for 1% of emergency department visits.1 Some causes of scrotal masses require rapid diagnosis and treatment to avoid loss of fertility or other complications.1–6 Table 1 summarizes the causes of scrotal masses.1,2,4,6–8
Normal testes are firm but not hard, nearly equal in size, smooth, and ovoid. Normal testicular length ranges from 1.5 to 2 cm before puberty and from 4 to 5 cm after puberty. The epididymis is posterolateral to the testicle; the epididymis and testicle are separated but attached. The vas deferens emanates from the tail of the epididymis and joins the vascular pedicle of the testicle to form the spermatic cord. The spermatic cord travels superiorly to the inguinal canal.3 Figure 1 illustrates the anatomy of the scrotum.9
|Clinical recommendation
|Evidence rating
Epididymitis/orchitis should be suspected in patients with testicular pain and a C-reactive protein level of more than 24 mg per L (228.6 nmol per L).
Any patient presenting with acute scrotal pain and a mass or swelling should be evaluated for testicular torsion by scrotal ultrasonography or surgical exploration within six hours of symptom onset.
Testicular torsion should be suspected in patients with rapid onset of acute unilateral scrotal pain and swelling, nausea or vomiting, high position of the testicle, and an abnormal cremasteric reflex.
A = consistent, good-quality patient-oriented evidence; B = inconsistent or limited-quality patient-oriented evidence; C = consensus, disease-oriented evidence, usual practice, expert opinion, or case series. For information about the SORT evidence rating system, go to http://www.aafp.org/afpsort.
|Clinical recommendation
|Evidence rating
Epididymitis/orchitis should be suspected in patients with testicular pain and a C-reactive protein level of more than 24 mg per L (228.6 nmol per L).
Any patient presenting with acute scrotal pain and a mass or swelling should be evaluated for testicular torsion by scrotal ultrasonography or surgical exploration within six hours of symptom onset.
Testicular torsion should be suspected in patients with rapid onset of acute unilateral scrotal pain and swelling, nausea or vomiting, high position of the testicle, and an abnormal cremasteric reflex.
A = consistent, good-quality patient-oriented evidence; B = inconsistent or limited-quality patient-oriented evidence; C = consensus, disease-oriented evidence, usual practice, expert opinion, or case series. For information about the SORT evidence rating system, go to http://www.aafp.org/afpsort.
Overview of the Causes of Scrotal Masses
|Clinical presentation
Testicular torsion
Clinical, with or without ultrasonography
Clinical, with or without ultrasonography
Ceftriaxone (Rocephin) and doxycycline
Torsion of the testicular appendage
Pain control
Hematocele or testicular rupture
Ultrasonography or surgical exploration
Pain control; surgery if needed
Testicular cancer
Ultrasonography, tumor markers
The Authors
PAUL CRAWFORD, MD, is program director of the Nellis Family Medicine Residency in Las Vegas, Nev. He is an associate professor at the Uniformed Services University of the Health Sciences in Bethesda, Md.
JUSTIN A. CROP, DO, is a faculty member at the Nellis Family Medicine Residency. He is an assistant professor at the Uniformed Services University of the Health Sciences.
The opinions and assertions contained herein are the private views of the authors and are not to be construed as official or as reflecting the views of the U.S. Army, Navy, or Air Force Medical Departments or the U.S. Army, Navy, Air Force, or Public Health Service.
Address correspondence to Paul Crawford, MD, Nellis Family Medicine Residency, 4700 Las Vegas Blvd. N, Nellis AFB, NV 89191 (e-mail: firstname.lastname@example.com). Reprints are not available from the authors.
1. Davis JE, Silverman M. Scrotal emergencies. Emerg Med Clin North Am. 2011;29(3):469–484.
2. Molokwu CN, et al. Outcomes of scrotal exploration for acute scrotal pain suspicious of testicular torsion. BJU Int. 2011;107(6):990–993.
3. Tajchner L, Larkin JO, Bourke MG, Waldron R, Barry K, Eustace PW. Management of the acute scrotum in a district general hospital: 10-year experience. ScientificWorldJournal. 2009;9:281–286.
4. Beni-Israel T, Goldman M, Bar Chaim S, Kozer E. Clinical predictors for testicular torsion as seen in the pediatric ED. Am J Emerg Med. 2010;28(7):786–789.
5. Boettcher M, Bergholz R, Krebs TF, Wenke K, Aronson DC. Clinical predictors of testicular torsion in children. Urology. 2012;79(3):670–674.
6. Montgomery JS, Bloom DA. The diagnosis and management of scrotal masses. Med Clin North Am. 2011;95(1):235–244.
7. Asgari SA, Mokhtari G, Falahatkar S, et al. Diagnostic accuracy of C-reactive protein and erythrocyte sedimentation rate in patients with acute scrotum. Urol J. 2006;3(2):104–108.
8. Tracy CR, Steers WD, Costabile R. Diagnosis and management of epididymitis. Urol Clin North Am. 2008;35(1):101–108.
9. Tiemstra JD, Kapoor S. Evaluation of scrotal masses. Am Fam Physician. 2008;78(10):1165–1170.
10. Akin EA, Khati NJ, Hill MC. Ultrasound of the scrotum. Ultrasound Q. 2004;20(4):181–200.
11. Kalfa N, Veyrac C, Lopez M, et al. Multicenter assessment of ultrasound of the spermatic cord in children with acute scrotum. J Urol. 2007;177(1):297–301.
12. Cokkinos DD, Antypa E, Tserotas P, et al. Emergency ultrasound of the scrotum: a review of the commonest pathologic conditions. Curr Probl Diagn Radiol. 2011;40(1):1–14.
13. Mano R, Livne PM, Nevo A, Sivan B, Ben-Meir D. Testicular torsion in the first year of life—characteristics and treatment outcome. Urology. 2013;82(5):1132–1137.
14. Workowski KA, Berman S; Centers for Disease Control and Prevention. Sexually transmitted diseases treatment guidelines, 2010 [published correction appears in MMWR Recomm Rep. 2011;60(1):18]. MMWR Recomm Rep. 2010;59(RR-12):1–110.
15. Mäkelä E, Lahdes-Vasama T, Rajakorpi H, Wikström S. A 19-year review of paediatric patients with acute scrotum. Scand J Surg. 2007;96(1):62–66.
16. Buckley JC, McAninch JW. Use of ultrasonography for the diagnosis of testicular injuries in blunt scrotal trauma. J Urol. 2006;175(1):175–178.
17. Yuan X, Wei G, Lin T, He D, Li X. Uncommon pediatric painless scrotal masses: a puzzle of pediatricians and urologists. Int Urol Nephrol. 2010;42(4):979–984.
18. Winter TC. There is a mass in the scrotum—what does it mean? Evaluation of the scrotal mass. Ultrasound Q. 2009;25(4):195–205.
19. Powell TM, Tarter TH. Management of nonpalpable incidental testicular masses. J Urol. 2006;176(1):96–98.
20. Eifler JB Jr, King P, Schlegel PN. Incidental testicular lesions found during infertility evaluation are usually benign and may be managed conservatively. J Urol. 2008;180(1):261–264.
21. Gentile G, Brunocilla E, Franceschelli A, et al. Can testis-sparing surgery for small testicular masses be considered a valid alternative to radical orchiectomy? A prospective single-center study. Clin Genitourin Cancer. 2013;11(4):522–526.
22. Kroese AC, de Lange NM, Collins J, Evers JL. Surgery or embolization for varicoceles in subfertile men. Cochrane Database Syst Rev. 2012;(10):CD000479.
23. de la Brassinne M, Richert B. Genital squamous-cell carcinoma after PUVA therapy. Dermatology. 1992;185(4):316–318.
24. Eliezri YD, Silverstein SJ, Nuovo GJ. Occurrence of human papillomavirus type 16 DNA in cutaneous squamous and basal cell neoplasms. J Am Acad Dermatol. 1990;23(5 pt 1):836–842.
25. Anaya DA, Dellinger EP. Necrotizing soft-tissue infection: diagnosis and management. Clin Infect Dis. 2007;44(5):705–710.
Copyright © 2014 by the American Academy of Family Physicians.
This content is owned by the AAFP. A person viewing it online may make one printout of the material and may use that printout only for his or her personal, non-commercial reference. This material may not otherwise be downloaded, copied, printed, stored, transmitted or reproduced in any medium, whether now known or later invented, except as authorized in writing by the AAFP. Contact firstname.lastname@example.com for copyright questions and/or permission requests.
Want to use this article elsewhere? Get Permissions
CME Quiz
More in AFP
Related Topic Searches
More in Pubmed
Email Alerts
Don't miss a single issue. Sign up for the free AFP email table of contents.


text:
Volvo MD 2B
View Single Post
Senior Moment Member
Join Date: Jun 2011
Location: West Vancouver B.C.
Posts: 11,321
Thanks: 59
Thanked 65 Times in 62 Posts
Rep Power:
Volvo MD 2B
I'm soliciting the members views & advice on the Volvo MD 2B. I am aware of the absurd prices for Volvo parts as well as the fact that this is an old engine but as you can see from the attached pic, this one has been very well cared for. It also has a custom stainless FWC manifold and cooler.
I spoke to a Volvo shop tech and he said they are stone axe reliable - basically Volvo quit making them because they lasted too long.
The hand start capability is attractive to me - that flywheel looks like it must weigh about the same as an entire Yannie of the same output.
The reason I ask is that the boat it's in is exactly what I'm looking for otherwise.
Attached Images
(42.9 KB, 28 views)
I, myself, personally intend to continue being outspoken and opinionated, intolerant of all fanatics, fools and ignoramuses, deeply suspicious of all those who have "found the answer" and on my bad days, downright rude.
View Public Profile
Send a private message to SloopJonB
Find all posts by SloopJonB


text:
Registration is now open for Studio School Courses, Art Adventures Programs, and Camps!
Studio School Adult Continuing Education Classes and Workshops
Online Studio School Registration Forms
Printable Fall Studio School Registration Form
Phone registration is also available Monday through Friday 9AM-3PM at 971.255.4201. Students wishing to apply a discount, gift certificate, credit or waiver must register by mail, fax or in person.
Art Adventures Youth and Teen Programs
Online Art Adventures + Teen Registration Form
Printable Fall Art Adventures + Teen Registration Form - Coming soon!
Sorry, phone registration is not available for Art Adventures.
Registration questions?
For Studio School or Art Adventures questions, please email email@example.com or call 971.255.4201.


text:
Clip From
August 27, 2013 Open Phones
Clip: Open Phones
Clip from Open Phones
Video Library clips and descriptions are created by MyC-SPAN users, and are not the editorial selections of C-SPAN.Report profane or abusive content
*The transcript for this program was compiled from uncorrected Closed Captioning.
People in this video
- Paul Orgel Host C-SPAN
Hosting Organization
More Videos From
Washington Journal, Tuesday Aug. 27More Videos
Clips from This VideoView all clips from this video
Related Video
Latest Developments in Syria
Scott Wilson, speaking by phone, talked about possible Obama administration actions regarding Syria.
Open Phones
Telephone lines were open for viewer comments on the question, "How should the U.S. respond in Syria?"
Open Phones
Telephone lines were open for viewer comments on the role of the international community in potential military action…
Latest Developments in Syria
Wall Street Journal Middle East correspondent Sam Dagher reported via Skype from Damascus about the latest round of…


text:
|Men's College Basketball
· Coaching changes
· Conferences
· Conference stats
· Gaming matchup
· Injuries (A-M)
· Injuries (N-Z)
· News
· Current odds
· Live odds
· Schedule
· Top 25 scoreboard
· Full scoreboard
· Statistics
· Associated Press
· USA Today Sports coaches poll
· Division II
· Division III
· Top-25 Analysis
· Top 25 Results
· Transactions
More Basketball
· Women
The Sports Network
DATE & TIME: Tuesday, November 12, 8 p.m. (et)
FACTS & STATS: Site: Memorial Gymnasium (14,316) -- Nashville, Tennessee. Television: None. Home Record: GSU 1-0, Vanderbilt 0-0. Away Record: GSU 0-0, Vanderbilt 0-0. Neutral Record: GSU 0-0, Vanderbilt 0-0. Conference Record: GSU 0-0, Vanderbilt 0-0. Series Record: Vanderbilt leads, 1-0.
GAME NOTES: After being left out of a busy college basketball tip-off weekend, the Vanderbilt Commodores will finally begin their 2013-14 campaign on Tuesday night when they host the Georgia State Panthers.
Although it finished just 15-16 last season, Georgia State comes into the new campaign as one of the favorites in the Sun Belt Conference thanks to the return of several keys players and the addition of high-profile transfer Ryan Harrow from Kentucky. The Panthers got their season started on the right foot this past Saturday against Southern Poly, winning easily in a 97-78 final.
Only a year removed from a their first SEC Tournament championship in 50 years, the Commodores endured a setback in 2012-13 by going just 16-17 and thus missing out on their third consecutive trip to the Big Dance. It was only Kevin Stallings' second losing season since taking over the program in 1999, and with a depleted roster in a strong SEC, it appears as though a similar fate could be in store this season.
In the only previous meeting between the teams, Vanderbilt defeated Georgia State at home on Dec. 27, 1979, 65-53.
Georgia State was not only fortunate to land Harrow (9.9 ppg in 2012-13), but to have him cleared to play this season, and he paid immediate dividends in the opener by tallying 20 points on 8-of-13 from the field, while also handing out six assists. Harrow's fantastic debut was overshadowed, however, by the play of R.J. Hunter, who posted 27 points (5-of-11 from 3-point range), seven rebounds and four assists. Devonta White (14 points, five assists) and Manny Atkins (13 points, nine rebounds) were also impressive in the Panthers' highest scoring game since 2007. GSU expects to have balanced efforts like that more often than not. In addition to Harrow, Hunter (17.0 ppg), White (14.8 ppg) and Atkins (14.2 ppg) all established themselves as potent scoring threats last season. Atkins (6.7 rpg) and Hunter (5.1 rpg) are expected to be active on the glass once again, and White (3.9 apg) is slated to be the floor general.
If the Commodores want return to relevancy this season, they'll need to do so without last season's top scorer Kedren Johnson (13.5 ppg, 3.6 apg). A pair of senior leaders will be expected to shoulder the load in 2013-14, with Rod Odom (10.4 ppg, 4.5 rpg) patrolling the paint while Kyle Fuller (8.7 ppg) brings a shooter's touch to the perimeter. Sophomore Eric McClellan, who sat out last season per NCAA transfer rules, put up 8.5 points per game for Tulsa in 2011-12 and will be a welcomed addition for a squad in desperate need of scorers. In Vanderbilt's exhibition contest -- in which it narrowly defeated Alabama-Huntsville (66-60) -- McClellan poured in 20 points, and James Siakam (six rebounds) started at forward after making only one start a season ago.
Vanderbilt will have a slight advantage playing in front of an eager home crowd, but that will only go so far as it appears to be inferior to Georgia State at the moment. The Panthers' deep stable of scorers will lead them to an impressive road victory.
Sports Network Predicted Outcome: Georgia State 75, Vanderbilt 67
Powered by The Sports Network.


text:
Borderlands 2
Which enemies (besides Pete) have been good to you when farming?
- Back To:
- Board List
- Topic List
- Topic Archived
So the last couple days, I've spent some time farming Hunter Helquist, Foreman Rusty, Slappy, and Bunker.
Hunter Helquist dropped a level 49 Bee after 5 kills. I killed him maybe another 10 times looking for a level 50, but no luck.
Foreman Rusty dropped a level 49 Blackhole after 2 kills, and a level 50 after another 3 kills. Thanks, buddy! My shock Gaige appreciates it.
Slappy dropped a level 49 Striker after about 8 kills. I didn't like it much, so I gave up farming him for now.
I've killed Bunker maybe 20 times tonight. He's dropped a better class mod and cooldown relic than the ones I had, but still no B***h, Digitized Death, Sham or tasty shock relic.
What about you guys? Which enemies have been quick, easy farms for you? I know Pete is awesome for drops, but I don't play multiplayer and I'm not super into using the Fibber glitch. I'm partly looking for advice on who to farm for better shock weapons and equipment for my mechromancer, but I'm curious about drop rates in general.
Between 3 playthroughs, I've killed Bunker probably 150 times, and only seen 1 Sham drop.
Currently playing: Borderlands 2, The Cave, Paper Mario: Sticker Star
Probably Foreman Rusty. 4 or 5 Blackholes dropped from him. Bunker has been absolute garbage for me. Warrior has been good. Dexiduous has been good for general gear. 1 Chopper and some good relics.
You can take my Karma, but you'll never take......MY FREEDOM!
Why don't you play with other people? (Not trying to start a fight w/you).
The Queen of Light took her bow, and then she turned to go.
The Prince of Peace embraced the gloom, and walked the night alone.-Battle of Evermore/Zeppelin
I have killed Hyperious probably 30 times and not a single orange drop. He is a d-bag.
I took down Dexidous 2 times (not on my own) and he dropped a bunch of purples.
I have gotten 2 Bees off Hunter Helmquist.
Terra drops a Slayer of Terra mods very frequently (for me at least).
NOPE! It's just Chuck Testa.
Laylow12 posted...
Why don't you play with other people? (Not trying to start a fight w/you).
I don't really enjoy multiplayer games, except for Minecraft or fighting games. Even games that are generally geared toward multiplayer (like Borderlands) I tend to prefer to play by myself.
Currently playing: Borderlands 2, The Cave, Paper Mario: Sticker Star
Pretty much anyone who is not The Warrior, Bunker, Doc Mercy, McNally, Flynt, and maybe a couple others have pretty reasonable drop rates customizations not withstanding. YMMV of course.
From: Ringlercorp | #004
Terra drops a Slayer of Terra mods very frequently (for me at least).
The class mod is a guaranteed drop, he always drops 1 for a random class.
XboxGT: KING JAMI
Bossanova - Blue Bossanova
knuckle dragger is an easy one, just travel to liarsburg and backtrack from there. It shouldn't take you long to get a Hornet.
Yeah...Well...Ya know...That's just like...Your opinion man.
havent farmed much in this game. however, during my playthroughs i've gotten a badaboom twice from king mong, a robbing leech (i think it's called) twice from the warrior, and the corrosive cloud grenade mod twice from mortar. these weren't through farming, I just happened to kill them during my playthroughs and they dropped on the first go each time, so i guess in a way you could say they were pretty generous.
other than one or two other legendary items frequently mentioned on this board, I don't really know the locations of many legendaries.
PSN: PSHustla | Steam:PC28385
XBOX LIVE: PC28385 | Twitch: http://www.twitch.tv/pc28385
Verm. Get a shock norfleet for gaige.
They're not going to say no because of the implication.


text:
I know that often times, developers and gamers alike don't really care what the rating on a game is, but from what I've heard (all speculation of course), is that Bungie is aiming for a "T" rating for Destiny. If this is the case, which I hope it isn't, it will be a huge mistake. The story for what Destiny is claiming to be, cannot be done justice if Bungie doesn't allow for the grit, violence, language, etc that would come with that setting, it can't be believable. If the world is almost completely wiped out, and the human race is having to fight several other species in a last ditch effort to survive, you better bet that there will be "F bombs" dropped, there will be people being shot (meaning decent amounts of blood), etc. Bungie, please, don't let yourselves be held back by a rating in order to get more sales. Make this game an "M" rated game. Anything less would be simply uncompelling and unbelievable, and would really detract from the story and mood that would be present should this situation in this game ever really happen.
Galactic Salami6/29/2014 7:41:11 PM PermalinkOkay I'm 12 and my mom is strict about M-rated games. I played the Alpha version for the PS4 and it seems like a really fun game and it didn't seem like an M-rated type of game. There was almost no language and barely any blood and I liked it just fine. Adding F bombs in every other word and adding 392052848921 pounds of blood just doesn't seem necessary. If you wanna play M-rated games go play COD.
L1nkW4rEdited by L1nkW4r: 6/29/2014 10:39:19 PM PermalinkThey can't rate it anything because it's an online game and they cannot predict the interactions you may have with other players.
Hierarch6/29/2014 10:37:54 PM PermalinkFirst, if you believe that there can be no violence or grit in a T rated game, you need to do some research. Second, if you think that strong language is necessary to tell a good story, to tell Destiny's story, well, I really don't know what to tell you. Other than to read some books, and again, do your research. Strong language is not needed to tell this story right. Besides, Guardians are respectable. They were brought back to life because they were worthy, because they could wield the Traveler's light. Finally, there is blood in the game. A realistic amount. When players/enemies get shot, they bleed. If you get shot near a wall, or even just standing (depending on the angle) you'll see blood splatter on the wall or ground. But not an overly-dramatized amount, like gamers are so used to.
Saturn6/29/2014 10:13:59 PM PermalinkIf you think an M rating will keep squeakers away, you have never played any multi player shooter.
Step 77/12/2013 6:44:01 AM PermalinkA T rating might not be that bad actually. COD has an M rating and its target audience is aimed at older teen and adults yet you still play with 12 year olds who can't control themselves. These kids play these games because of the M rating in my opinion. I think with a T rating would have kind of the opposite affect (hoping anyways). I bet Destiny would have a more mature audience if those 12 years olds saw the "T" rating and thought "nah that game if for kids" Just my opinion though
Leif Ericson6/29/2014 8:41:16 PM PermalinkBungie is not holding themselves back. Did George Lucas hold Star Wars (the first three) back by infusing them with an often light hearted demeanor? No, didn't think so.
AYZY886/29/2014 8:38:46 PM PermalinkThere's no doubt it's going to be an "M" rated game I've seen enough of it to be that
Muddy Armadillo1/28/2014 2:17:28 AM Permalink[quote]I need M-rated games to feel mature and tough.[/quote] There's your new title.
TroopuRR1/10/2014 9:08:49 PM PermalinkI never knew that what makes or breaks the game is the esrb rating... (pegi for some) that's retarded. I have never went to or shyed away from any game for its rating nor should anyone. Its irrelevent. Its about how fun the game is. The story doesn't need blood or people saying "-blam!-." And it probably won't. If bungies shooting for T, they'll probably get it,
Overkill1/9/2014 11:07:13 PM PermalinkI suggest an eC rating. eC is the rating given to most Dora the Explorer games. Thank you.
GrandpaCarl3/1/2014 8:36:53 PM PermalinkBasically, all I have to say is... YOU MRSAXOPHONE18 HAVE NO TASTE IN GAMES. Like DeeJ said, they are making the game they want to play. Plus, in my opinion, the Blood/Gore/Swearing/Profanity in some games has no reason to be there. JUDGE ME. YOU WILL BE IGNORED.
Ralok1/9/2014 5:23:21 AM Permalinknever... ever...ever aim for a rating, create what you want to create and let raters decide.
So Hood6/24/2014 4:00:18 PM PermalinkFor the sake of kids 11-14 years old I say put a T rating. Some of their parents are strict with the M rating games. Hey, we were all kids once. Live and let live.
Heath6/27/2014 12:14:25 PM PermalinkYou have obviously never played a Bungie game. They know how to make an excellent game and keep it clean. More devs should try it
SpongyMallard76/24/2014 4:09:30 PM PermalinkI know this is an old tread, but I'm sure people still want it rated "M". Let me tell you a story. A man who works as a delivery boy. One day he opens a package and half the population of a city is killed by the energy of their brain being ripped out and then their bodies incinerated. All of this energy is absorbed into the man who opened the package. He then awakens in a crater the size of a city block and the aftermath is seen throughout the entire city. Then a plague is found that has infected everyone inside the city except for a select few. The disease slowly kills the person with symptoms of an extreme cold. This is inFAMOUS. Don't use the story of Destiny to think it would get an "M" rating. Oh and anyone thinking an M rated game will keep young kids out. You clearly have never played Halo or always mute everyone.
Wolfy of Elsweÿr6/23/2014 12:59:16 AM PermalinkYou obviously dont understand this First they [i]make[/i] the game [i][u]THEN[/u][/i] they rate it ESRB doesn't give you restrictions on what you can put in the game, lol..
Jameskca6/22/2014 11:32:11 PM PermalinkI am 14 and my parents are very strict. They will not ever let me play a game with a "m" on it. Call of Duty Classic is rated T, and so is Warface. Both of these are games that are not bad they are fun and still cuss and such. The M on the box makes the company less money. They if it is rated M will lose out on my 74.32
kid16/20/2014 10:30:42 PM Permalinkthatperson is right if you look at Amazon it is rated T for Teen! (link in comment)
Thatperson6/16/2014 8:26:36 PM PermalinkWhen I was on amazon looking at the white ps4 bundle, on the side of the box you can clearly see the rating is teen


text:
UPDATED: MINI's All4 System and "100% Power to the Rear Wheels"
Sections: Official News, R60 (Countryman), R61 (Paceman), Safety, Technology Dec 19th, 2012 21 Comments
[UPDATE] We've reached out to our sources at MINI and received clarification on BMW's announcement last week concerning what appeared to be an update to the ALL4 system. We reported on BMW's description of the system sending 100% of the power to the rear wheels. However, we also expressed skepticism that perhaps this was an example of MINI and BMW having trouble consistently communicating the details of this system. Our sources are telling us that in actual fact, it's a little of both.
So let's clear this up. The ALL4 system can split power 50/50 between the front and rear wheels. It can also put 100% of power to the front wheels. In the case of no traction to the front wheels, it can send all of its available power to the rear wheels, but MINI is saying explicitly that this is still only 50% of the car's total power. So what BMW described is, in a sense, correct (in that the car will be RWD for that instant); but the chosen language did not account for this nuance.
Descriptions notwithstanding, MINI has also confirmed explicitly that the ALL4 system has not changed for 2013. It's the same system the Countryman shipped with in 2010. I repeat, it has not been updated. This post, on the other hand, now has.
Original story after the jump. continued →