This project has retired. For details please refer to its Attic page.
Jini Lease Renewal Service Specification
Spec Index A Collection of Jini Technology Helper Utilities and Services Specifications

Version 1.0

LR - JiniTM Lease Renewal Service Specification

LR.1 Introduction

Leasing is a key concept in the JiniTM architecture; in general, Jini technology-enabled services (Jini services) grant access to a resource only for as long as the clients of those Jini services actively express interest in the resource being maintained. This pattern is in contrast to many other systems, in which access to a resource is granted until the client explicitly releases the resource. Using a leasing model generally makes a distributed system more robust by allowing stale information and services to be cleaned up, but it also places additional requirements on clients and services.

A client of a leased service may run into difficulties if that client deactivates. Unless the client ensures that some other process renews the client's leases while it is inactive, or that the client is activated before its leases begin to expire, the client will lose access to the resources it has acquired. This loss can be particularly dramatic in the case of lookup service registrations. A service's registration with a lookup service is leased--if the service deactivates (maybe to conserve computational resources on its host) and it does not take appropriate steps, its registrations with lookup services will expire, and before long it will be inaccessible. If that service becomes active only when clients invoke its methods, it may never become active again, because at this point new clients may not be able to find it.

The need to renew leases creates a constant load on clients, servers, and the network. Although batching lease renewals can help (see the Jini Distributed Leasing Specification), a given client is unlikely to have very many leases granted by any one service at any given time, thus reducing the opportunities for meaningful batching.

This additional load may be an especially great burden on clients that always have the ability to access the network but cannot be continuously connected. A cell phone always has the ability to connect; however, being connected all the time will drain its batteries and accumulate airtime charges. One or two leases may not pose a problem, but a large number of leases could force the phone to be on the network all the time.

A lease renewal service can help mitigate these problems. Clients that wish to become inactive can pass the responsibility for renewing the leases they have been granted to a renewal service. Those clients can then deactivate without risk of losing access to the resources that they have acquired. Clients that have continuous access to the network but cannot be continuously connected, such as the cell phone described previously, can also register with a renewal service that can be continuously connected. The renewal service will renew the client's leases, allowing the client to remain disconnected most of the time. Lastly, if multiple clients pass their leases to a given renewal service, more opportunities for batching renewals will be created.

Like other Jini services, the lease renewal service will grant its services for only a limited period of time without an active expression of continuing interest. To break the recursive cycle that would otherwise result, the renewal service provides an optional event that is triggered before the leases that it grants expire. This event gives activatable processes that have deactivated the opportunity to wake up and renew their lease with the renewal service. Although it may seem odd for the lease renewal service to lease its resources, it is very important that it does so. If it did not, then the lease renewal service could be used to subvert the leasing model.

Lease renewal services are likely to grant longer leases than other Jini services. In some cases the lease may be so long that the client will not need to worry about renewing the lease at all. In other cases the lease may be long enough that a client that deactivates will rarely need to reactivate for the sole purpose of renewing its lease with the renewal service. In any case, the leases that the renewal service grants are likely to be sufficiently long such that the actual renewal calls do not place a significant additional load on the client, the renewal service, or the network.

LR.1.1 Goals and Requirements

The requirements of the set of classes and interfaces in this specification are:

The goals of this specification are:

LR.1.2 Other Types

The types defined in the specification of the LeaseRenewalService interface are in the net.jini.lease package. The following object types may be referenced in this chapter. Whenever referenced, these object types will be referenced in unqualified form: 

java.io.IOException
java.rmi.MarshalledObject
java.rmi.RemoteException
java.rmi.NoSuchObjectException
net.jini.core.lease.Lease
net.jini.core.lease.UnknownLeaseException
net.jini.core.event.RemoteEvent
net.jini.core.event.RemoteEventListener
net.jini.core.event.EventRegistration

LR.2 The Interface

The LeaseRenewalService (in the net.jini.lease package) defines the interface to the renewal service. The interface is not a remote interface; each implementation of the renewal service exports proxy objects that implement the LeaseRenewalService interface local to the client, using an implementation-specific protocol to communicate with the actual remote server. All of the proxy methods obey normal Java(TM) Remote Method Invocation (Java RMI) remote interface semantics. Two proxy objects are equal (using the equals method) if they are proxies for the same renewal service. All the methods of LeaseRenewalService throw RemoteException and require only the default serialization semantics. Therefore, LeaseRenewalService can be implemented directly using Java RMI. 

package net.jini.lease;

public interface LeaseRenewalService {
    public LeaseRenewalSet createLeaseRenewalSet(
            long leaseDuration) 
        throws RemoteException;
}

Clients of the renewal service organize the leases they wish to have renewed into lease renewal sets (or sets, for short). A method is provided by the LeaseRenewalService interface to create these sets. These sets are then populated by methods on the sets themselves. Two leases in the same set need not be granted by the same service or have the same expiration time; in addition, they can be added or removed from the set independently.

Every method invocation on a renewal service (whether the invocation is directly on the service or indirectly on a set the service has created) is atomic with respect other invocations.

The term client lease is used to refer to a lease that has been placed into a renewal set. Client leases are distinct from the leases that the renewal service grants on renewal sets it has created.

In general, there will be times when an implementation of the renewal service needs to pass one client lease as an argument to a method call on a second client lease. There is a security risk in doing so, because such actions can let the second client lease "capture" the first.Implementations may want to verify that their clients can be trusted not to place leases in the set that would take such actions, or may choose to avoid passing client leases to each other if the leases are contained in different sets.

Each client lease has two expiration related times associated with it: the desired expiration time for the lease and the actual expiration time granted when the lease is created or last renewed. The desired expiration represents when the client would like the lease to expire. The actual expiration represents when the lease is going to expire if it is not renewed. Both time values are absolute times, not relative time durations. When a client lease's desired expiration arrives, the lease will be removed from the set without further client intervention.

Each client lease also has two other associated attributes: a renewal duration and a remaining desired duration. The remaining desired duration is always the desired expiration less the current time. The renewal duration is usually a positive number and represents the duration that will be requested when the renewal service renews the client lease, unless the renewal duration is greater than the remaining desired duration. If the renewal duration is greater than the remaining desired duration, then the remaining desired duration will be requested when renewing the client lease. One exception is that when the desired expiration is Lease.FOREVER, the renewal duration may be Lease.ANY, in which case Lease.ANY will be requested when renewing the client lease, regardless of the value of the remaining desired duration.

For example, if the renewal duration associated with a given client lease is 360,000 milliseconds, then when the renewal service renews the client lease, it will ask for a new duration of 360,000 milliseconds--unless the client lease is going to reach its desired expiration in less than 360,000 milliseconds. If the client lease's desired expiration is within 360,000 milliseconds, the renewal service will ask for the difference between the current time and the desired expiration. If the renewal duration had been Lease.ANY, the renewal service would have asked for a new duration of Lease.ANY.

If a lease's actual expiration is later than the lease's desired expiration, the renewal service will not renew the lease; the lease will remain in the set until its desired expiration is reached, the set is destroyed, or it is removed by the client.

Each set is leased from the renewal service. If the lease on a set expires or is cancelled, the renewal service will destroy the set and take no further action with regard to the client leases in the set. Each lease renewal set has associated with it an expiration warning event that occurs at a client-specified time before the lease on the set expires. Clients can register for warning events using methods provided by the set. A registration for warning events does not have its own lease, but instead is covered by the same lease under which the set was granted.

The term definite exception is used to refer to an exception that could be thrown by an operation (such as a remote method call) on an object, for example a client lease, that would be indicative of a permanent failure of that object. The term indefinite exception refers to exceptions that would not imply anything about the probability of success of any future operations on the object. The algorithm used to classify exceptions as definite or indefinite is implementation-specific.

Each lease renewal set has associated with it a renewal failure event that will occur in either of two cases: if any client lease in the set reaches its actual expiration before its desired expiration is reached, or if the renewal service attempts to renew a client lease and gets a definite exception. Clients can register for failure events using methods provided by the set. A registration for failure events does not have its own lease but instead is covered by the same lease under which the set was granted.

Once placed in a set, a client lease will stay there until one or more of the following occurs:

Each client lease in a set will be renewed as long as it is in the set. If a renewal call throws an indefinite exception, the renewal service should retry the lease renewal until the lease would otherwise be removed from the set. The preferred method of cancelling a client lease is for the client to first remove the lease from the set and then call cancel on it. It is also permissible for the client to cancel the lease without first removing the lease from the set, although this is likely to result in additional network traffic.

The client creates a set by calling the createLeaseRenewalSet method of a LeaseRenewalService. The leaseDuration argument specifies how long (in milliseconds) the client wants the set's initial lease duration to be. The duration initially granted for the set's lease will be equal to or shorter than this request; it will not be longer. The value of the leaseDuration argument must be positive, Lease.FOREVER, or Lease.ANY; otherwise, an IllegalArgumentException will be thrown. Two calls to the createLeaseRenewalSet method will never return objects that are equal. The set's lease is obtained through a method provided by the set.

LeaseRenewalSet defines the interface to the sets created by the lease renewal service. This interface is not a remote interface. Each implementation of the renewal service exports proxy objects that implement the LeaseRenewalSet interface local to the client and use an implementation-specific protocol to communicate with the actual remote server. All of the proxy methods obey normal Java RMI remote interface semantics except where explicitly noted. The proxy objects for two sets are equal (using the equals method) if they are proxies for the same set created by the same renewal service. Any method that communicates with the remote server should throw a NoSuchObjectException if the set no longer exists. If a client receives a NoSuchObjectException from one of the operations on a lease renewal set, the client can infer that the set has been destroyed; however, it should not infer that the renewal service has been destroyed. 

package net.jini.lease;

public interface LeaseRenewalSet {
    final public static long RENEWAL_FAILURE_EVENT_ID = 0;
    final public static long EXPIRATION_WARNING_EVENT_ID = 1;

    public void renewFor(Lease leaseToRenew,
                     long  desiredDuration,	 
                     long  renewDuration)
        throws RemoteException;

    public void renewFor(Lease leaseToRenew, 
                         long  desiredDuration)
        throws RemoteException;
    
    public EventRegistration setExpirationWarningListener(
            RemoteEventListener listener, 
            long                minWarning, 
            MarshalledObject    handback)
        throws RemoteException;

    public void clearExpirationWarningListener()
        throws RemoteException;

    public EventRegistration setRenewalFailureListener(
            RemoteEventListener listener, 
            MarshalledObject    handback)
        throws RemoteException;

    public void clearRenewalFailureListener()
        throws RemoteException;

    public Lease remove(Lease leaseToRemove) 
        throws RemoteException;
   
    public Lease[] getLeases() 
        throws LeaseUnmarshalException, RemoteException;

    public Lease getRenewalSetLease();
}

Leases can be added to the set through the renewFor methods. There are two forms of this method: a three-argument form and a two-argument form. The three-argument form will be described first. The leaseToRenew argument specifies the lease to be renewed. An IllegalArgumentException will be thrown if the lease has not expired and was granted by the renewal service itself. If leaseToRenew is null, a NullPointerException will be thrown.

The desiredDuration parameter is the number of milliseconds that the client would like for the client lease to remain in the set. It is used to calculate the client lease's desired expiration by adding desiredDuration to the current time (as viewed by the service). If this causes an overflow, a desired expiration of Long.MAX_VALUE will be used. Unlike a lease duration, the desired duration is unilaterally specified by the client, not negotiated between the client and the service. Note that a negative value for desiredDuration (including Lease.ANY) will result in a desired expiration that is in the past. This will cause the client lease to be dropped immediately from the set and will not result in an exception. A renewal failure event will be generated if and only if the client's actual expiration is before its desired expiration.

If the actual expiration time of the client lease being added to the set is before both the current time (as viewed by the renewal service) and the client lease's desired expiration time, the method will return normally. However, the client lease will be dropped from the set, and a renewal failure event will be generated. If the actual expiration time is before the current time and equal to or after the desired expiration time, the method will return normally, the client lease will be dropped from the set, and no event will be generated.

A desiredDuration of Long.MAX_VALUE does not imply that the client lease will remain in the set forever. The client lease will be ejected from the set if the set is destroyed, the client lease itself expires, the client lease is removed from the set, or the renewal service makes a renewal attempt on the client lease that results in a definite exception.

The renewDuration is the renewal duration to associate with the client lease (in milliseconds). If desiredDuration is exactly Long.MAX_VALUE, the renewDuration may be any positive number or Lease.ANY; otherwise it must be a positive number. If these requirements are not met, the renewal service will throw an IllegalArgumentException.

Calling renewFor with a lease that is equivalent to a client lease already in the set will associate the existing client lease in the set with the new desired duration and renew duration. The original copy of the client lease is not replaced with the new one. These semantics also allow renewFor to be used in an idempotent fashion.

The two-argument form of renewFor is equivalent to 

renewFor(leaseToRenew, desiredDuration, Lease.FOREVER)

Client leases get returned to clients in a number of ways (via remove and getLeases calls, as components of events, etc.). The serial format of client leases returned to clients may be either Lease.DURATION or Lease.ABSOLUTE. In particular it may be necessary to use the Lease.ABSOLUTE format if the implementation has access to the client lease only in marshalled form and is unable to unmarshal the client lease before sending it to the client.

Whenever a client lease gets returned to a client, its actual expiration should reflect either:

Although it is impossible for a renewal service to guarantee that all renewal attempts will be recorded, persistent implementations should attempt to keep the interval between the renewal of a client lease and the logging of the result to a minimum.

Client leases are removed from the set by using the remove method. Removal from the set will not cause the lease to be cancelled. The method will return the lease that is being removed. If the lease is not in the set, null will be returned; and this call will not be blocked by in-progress renewal attempts. As a result, a client lease removed by this method might be renewed after the method has returned. Implementations should keep the window where renewals of removed leases could occur as small as possible.

The getLeases method returns all the client leases in the set at the time of the call, as an array of type Lease. If one or more of the Leases in the array cannot be deserialized, a LeaseUnmarshalException is thrown. 

package net.jini.lease;

public class LeaseUnmarshalException extends Exception {
    public LeaseUnmarshalException(
            Lease[]            leases,
            MarshalledObject[] marshalledLeases,
            Throwable[]        exceptions) {...}
    public LeaseUnmarshalException(
            Lease[]            leases,
            MarshalledObject[] marshalledLeases,
            Throwable[]        exceptions,
            String             message) {...}

    public Lease[] getLeases() {...}
    public MarshalledObject[] getMarshalledLeases() {...}
    public Throwable[] getExceptions() {...}
}

The leases that could be successfully deserialized will be returned by the getLeases method of the exception. If no leases could be deserialized, a zero-length array will be returned. The leases that could not be deserialized will be returned in the form of MarshalledObjects by the getMarshalledLeases method of the exception. For each element of the array returned by the getMarshalledLeases method, the corresponding element of the array returned by the getExceptions method will hold a Throwable that indicates why the given lease could not be deserialized.

Throwing a LeaseUnmarshalException represents a (possibly transient) failure in the ability to unmarshal one or more client leases in the set; it does not necessarily imply anything about the state of the renewal service or the set that threw the exception.

The getRenewalSetLease method of LeaseSet returns the lease associated with the set itself. This method does not make a remote call.

LR.2.1 Events

The lease renewal service does not support multiple simultaneous event listener registrations for the same kind of event. Although it would be useful in some limited circumstances, to do so would require event registrations to be leased separately from the set they are associated with. For the average client of the lease renewal service, this ability would increase the number of leases that it would have to manage. Since the renewal service is based on the premise that some clients have difficulty managing their own leases, increasing the number of leases that a client would need to manage could significantly complicate the implementation of those clients. Because there can be at most one listener for each kind of event, a given set provides a set/clear interface instead of the more common addListener/removeListener or addListener/lease.cancel interfaces.

The source field of each event generated by a lease renewal service is the renewal set that the event is associated with. In the case of an expiration warning event, this is the set that is about to expire. In the case of a renewal failure event, this is the set the client lease was in when the event occurred. Note that the value of the source field will in general be a copy of the set in question, the equals method will return true for any other copies of the set the client has in its possession, but in general it will not be the same object (that is, comparing two sets using == will usually return false).

The event ID LeaseRenewalSet.EXPIRATION_WARNING_EVENT_ID is used for all expiration warning events. One event ID is used because there is only one kind of expiration warning event. Similarly, all renewal failure events will have the event ID LeaseRenewalSet.RENEWAL_FAILURE_EVENT_ID.

Because all of the expiration warning events generated by a given set will have the same source and event ID, the sequence number of any given expiration warning event generated by the set will be different from the sequence number of any other expiration warning event generated by the set. Similarly, the sequence number of any renewal failure event generated by a given set will be different from the sequence number of any other renewal failure event generated by the set. Two different events with the same source and event ID will have different sequence numbers even if different event registration were in effect when each event was generated.

If a RemoteEventListener registered for a renewal failure or expiration warning event throws an UnknownEventException, this action will only clear the specific event registration. It will not cancel the lease on the renewal set or affect any other event registration on the set. If the listener throws a definite exception, the renewal service may clear that specific event registration; it will not clear any registration associated with other listeners, nor will it cancel the lease on the associated renewal set.

If an event listener is replaced and one or more event delivery attempts on the original listener failed, implementations may choose to send some or all of these events to the new listener.

Event listeners may receive notification of events that they are no longer registered to receive, if those events occurred before they were unregistered. Implementations should keep the window where such notifications could occur as small as possible.

The setExpirationWarningListener method of LeaseRenewalSet allows the client to register for notification of the approaching expiration of the set's lease. Expiration warning events are not generated for client leases. The listener argument specifies which listener should be notified when the set's lease is about to expire. The minWarning argument specifies the minimum number of milliseconds before set lease expiration that the first event delivery attempt should be made by the service. The service may also make subsequent delivery attempts if the first and any subsequent attempts resulted in an indefinite exception. The minWarning argument must be zero or a positive number; if it is not, an IllegalArgumentException must be thrown. If the current expiration of the set's lease is less than minWarning milliseconds away, the event will occur immediately (though it will take time to propagate to the handler).

The handback argument to setExpirationWarningListener specifies an object that will be part of the expiration warning event notification. This mechanism is detailed in the Jini Distributed Events Specification.

The setExpirationWarningListener method returns the event registration for this event. The Lease object associated with the registration will be equivalent (in the sense of the equals method) to the Lease on the renewal set. Because the event registration shares a lease with the set, clients that want to just remove their expiration warning registration without destroying the set should use the clearExpirationWarningListener method described below, instead of cancelling the registration's lease. The event ID returned with the registration will be LeaseRenewalSet.EXPIRATION_WARNING_EVENT_ID. The source of the registration will be the set. The method will throw a NullPointerException if the listener argument is null. If an event handler has already been specified for this event, the current registration is replaced with the new one. Because both registrations are for the same kind of event, the events sent to the new registration must be in the same sequence as the events sent to the old registration.

The clearExpirationWarningListener method of LeaseRenewalSet removes the event registration currently associated with the approaching expiration of the set's lease. It is acceptable to call this method even if there is no active registration.

The setRenewalFailureListener method of LeaseRenewalSet allows the client to register for the event associated with the failure to renew a client lease in the set. These events are generated when a client lease in the set reaches its actual expiration before its desired expiration or when the service attempts to renew a client lease and gets a definite exception. The listener argument specifies the listener to be notified if a client lease could not be renewed.

The handback argument to setRenewalFailureListener specifies an object that will be part of the renewal failure event notification. This mechanism is detailed in the Jini Distributed Events Specification.

The setRenewalFailureListener method returns the event registration for this event. The Lease object associated with the registration will be equivalent (in the sense of the equals method) to the Lease on the renewal set. Because the event registration shares a lease with the set, clients that want to just remove their expiration warning registration without destroying the set should use the clearRenewalFailureListener method (described below) instead of cancelling the registration's lease. The registration ID returned with the registration will be LeaseRenewalSet.RENEWAL_FAILURE_EVENT_ID. The source of the registration will be the set. The method will throw NullPointerException if the listener argument is null. If an event handler has already been specified for this event, the current registration is replaced with the new one. Because both registrations are for the same kind of event, the events sent to the new registration must be in the same sequence as the events sent to the old registration.

The clearRenewalFailureListener method of LeaseRenewalSet removes the event registration currently associated with the failure to renew client leases. It is acceptable to call this method even if there is no active registration. 

package net.jini.lease;

public class ExpirationWarningEvent extends RemoteEvent {
    public ExpirationWarningEvent(
            LeaseRenewalSet  source,
            long             seqNum,
            MarshalledObject handback) {...}
    public Lease getRenewalSetLease() {...}
}

ExpirationWarningEvent objects are passed to the event handlers specified in calls to the LeaseRenewalSet method, setExpirationWarningListener. The ExpirationWarningEvent is a subclass of RemoteEvent and adds no additional state. Because the source of a ExpirationWarningEvent is the set that is about to expire, the lease that needs to be renewed can be obtained by: calling getSource, casting the result to a LeaseRenewalSet and then invoking the set's getRenewalSetLease method. The convenience method getRenewalSetLease in ExpirationWarningEvent uses this technique to retrieve the lease on the set. The Lease object returned will be equivalent (in the sense of the equals method) to other Lease objects associated with the set but may not be the same object. One notable consequence of having two different objects is that the getExpiration method of the Lease object returned by the event's getRenewalSetLease method may return a different time than the getExpiration methods of other Lease objects granted on the same set.

The expiration time associated with the Lease object returned by the getRenewalSetLease method will reflect the expiration the lease had when the event occurred. Renewal calls may have changed the expiration time of the underlying lease between the time when the event was generated and when it was delivered.

Other aspects of the event's state are described in the Jini Distributed Events Specification. Sequence numbers for a given event ID are increasing. If there is no gap between two sequence numbers, no events have been missed; if there is a gap, events might (but might not) have been missed. 

package net.jini.lease;

public abstract class RenewalFailureEvent
    extends RemoteEvent
{
    public RenewalFailureEvent(LeaseRenewalSet  source,
                               long             seqNum,
                               MarshalledObject handback) {...}
    abstract public Lease getLease() 
        throws IOException, ClassNotFoundException;
    abstract public Throwable getThrowable()
        throws IOException, ClassNotFoundException;
}

RenewalFailureEvent objects are passed to the event handlers specified in calls to the LeaseRenewalSet method, setRenewalFailureListener. The RenewalFailureEvent is a subclass of RemoteEvent, adding two additional items of abstract state: the client lease that could not be renewed before expiration and the Throwable object that was thrown by the last recorded renewal attempt (if any). The client lease is returned by the getLease method, and the Throwable object is returned by the getThrowable method. If the Throwable object is null, it can be assumed that during the time between the last-recorded, successful renewal (or when the client lease was added to the set if there have been no renewals) and the actual expiration time of the client lease the renewal service was either unable to attempt a renewal of the client lease, or that it attempted a renewal but was unable to record the result.

Both the getLease and getThrowable methods may throw IOException or ClassNotFoundException. This declaration allows implementations to delay unmarshalling this state until it is actually needed. Once either method of a given RenewalFailureEvent object returns normally, future calls on that method must return the same object and may not throw an exception.

If the renewal service was able to renew the client lease and record the result before the event occurred, the expiration time of the Lease object returned by the event's getLease method will reflect the result of the last-recorded successful renewal call. Note that this time may be distorted by clock skew between hosts if it is currently set to use the Lease.ABSOLUTE serial format. If the Lease object is using the Lease.DURATION serial format, and the event only unmarshals the lease when getLease is called, the expiration time may be distorted if a long time has passed between the time the event was generated by the renewal service and when the client called getLease. When a renewal failure event is generated for a given lease, that lease is removed from the set.

The event's other state is described in the Jini Distributed Events Specification. Sequence numbers for a given event ID are increasing. If there is no gap between two sequence numbers, no events have been missed; if there is a gap, events might (but might not) have been missed.

LR.2.2 Serialized Forms

Class
 serialVersionUID
 Serialized Fields
RenewalFailureEvent
 889145704195932943L
 none
ExpirationWarningEvent
 -2020487536756927350L
 none
LeaseUnmarshalException
 -6736107321698417489L
 Lease[]unmarshalledLeases
MarshalledObject[]
stillMarshalledLeases
Throwable[] exceptions

LR.3 History
Version Description
v1.0 Initial release of this specification.

License

Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Spec Index A Collection of Jini Technology Helper Utilities and Services Specifications
Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.