remove refs to akka versions (#256)
This commit is contained in:
PJ Fanning
GitHub
parent
eb660940b6
commit
1836c952f9
26 changed files with 50 additions and 56 deletions
|
|
@ -828,7 +828,7 @@ That has benefits such as:
|
|||
The @javadoc[Receive](pekko.actor.AbstractActor.Receive) can be implemented in other ways than using the `ReceiveBuilder` since in the
|
||||
end, it is just a wrapper around a Scala `PartialFunction`. In Java, you can implement `PartialFunction` by
|
||||
extending `AbstractPartialFunction`. For example, one could implement an adapter
|
||||
to [Vavr Pattern Matching DSL](https://docs.vavr.io/#_pattern_matching). See the [Pekko Vavr sample project](https://github.com/apache/incubator-pekko-samples/tree/2.5/akka-sample-vavr) for more details.
|
||||
to [Vavr Pattern Matching DSL](https://docs.vavr.io/#_pattern_matching). See the [Akka Vavr sample project](https://github.com/akka/akka-samples/tree/2.5/akka-sample-vavr) for more details.
|
||||
|
||||
If the validation of the `ReceiveBuilder` match logic turns out to be a bottleneck for some of your
|
||||
actors you can consider implementing it at a lower level by extending @javadoc[UntypedAbstractActor](pekko.actor.UntypedAbstractActor) instead
|
||||
|
|
|
|||
|
|
@ -253,8 +253,8 @@ An example is provided to illustrate an approach to migrate from the deprecated
|
|||
with minimal changes to your existing code. The example is intended to be copied and adjusted to your needs.
|
||||
It will not be provided as a published artifact.
|
||||
|
||||
* [pekko-samples/pekko-bom-sample-cluster-cluster-client-grpc-scala](https://github.com/apache/incubator-pekko-samples/tree/2.6/pekko-bom-sample-cluster-client-grpc-scala) implemented in Scala
|
||||
* [pekko-samples/pekko-bom-sample-cluster-cluster-client-grpc-java](https://github.com/apache/incubator-pekko-samples/tree/2.6/pekko-bom-sample-cluster-client-grpc-java) implemented in Java
|
||||
* [pekko-samples/pekko-sample-cluster-cluster-client-grpc-scala](https://github.com/apache/incubator-pekko-samples/tree/main/pekko-sample-cluster-client-grpc-scala) implemented in Scala
|
||||
* [pekko-samples/pekko-sample-cluster-cluster-client-grpc-java](https://github.com/apache/incubator-pekko-samples/tree/main/pekko-sample-cluster-client-grpc-java) implemented in Java
|
||||
|
||||
The example is still using an actor on the client-side to have an API that is very close
|
||||
to the original Cluster Client. The messages this actor can handle correspond to the
|
||||
|
|
|
|||
|
|
@ -29,18 +29,12 @@ Binary compatibility is **NOT** maintained between:
|
|||
Specific examples:
|
||||
|
||||
```
|
||||
# [epoch.major.minor] era
|
||||
OK: 2.2.0 --> 2.2.1 --> ... --> 2.2.x
|
||||
NO: 2.2.y --x 2.3.y
|
||||
OK: 2.3.0 --> 2.3.1 --> ... --> 2.3.x
|
||||
OK: 2.3.x --> 2.4.x (special case, migration to new versioning scheme)
|
||||
# [major.minor.patch] era
|
||||
OK: 2.4.0 --> 2.5.x
|
||||
OK: 2.5.0 --> 2.6.x
|
||||
NO: 2.x.y --x 3.x.y
|
||||
OK: 3.0.0 --> 3.0.1 --> ... --> 3.0.n
|
||||
OK: 3.0.n --> 3.1.0 --> ... --> 3.1.n
|
||||
OK: 3.1.n --> 3.2.0 ...
|
||||
OK: 1.4.0 --> 1.5.x
|
||||
OK: 1.5.0 --> 1.6.x
|
||||
NO: 1.x.y --x 2.x.y
|
||||
OK: 2.0.0 --> 2.0.1 --> ... --> 2.0.n
|
||||
OK: 2.0.n --> 2.1.0 --> ... --> 2.1.n
|
||||
OK: 2.1.n --> 2.2.0 ...
|
||||
...
|
||||
```
|
||||
|
||||
|
|
@ -60,15 +54,17 @@ Some modules are excluded from the binary compatibility guarantees, such as:
|
|||
|
||||
### When will a deprecated method be removed entirely
|
||||
|
||||
Once a method has been deprecated then the guideline* is that it will be kept, at minimum, for one **full** minor version release. For example, if it is deprecated in version 2.5.2 then it will remain through the rest of 2.5, as well as the entirety of 2.6.
|
||||
Once a method has been deprecated then the guideline* is that it will be kept, at minimum, for one **full** minor version release. For example, if it is deprecated in version 1.0.2 then it will remain through the rest of 1.0, as well as the entirety of 1.1.
|
||||
|
||||
Methods that were deprecated in Akka, before the project fork to Pekko, are being considered for removal in Pekko 1.1.0.
|
||||
|
||||
*This is a guideline because in **rare** instances, after careful consideration, an exception may be made and the method removed earlier.
|
||||
|
||||
## Mixed versioning is not allowed
|
||||
|
||||
Modules that are released together under the Pekko project are intended to be upgraded together.
|
||||
For example, it is not legal to mix Pekko Actor `2.6.2` with Pekko Cluster `2.6.5` even though
|
||||
"Pekko `2.6.2`" and "Pekko `2.6.5`" *are* binary compatible.
|
||||
For example, it is not legal to mix Pekko Actor `1.0.0` with Pekko Cluster `1.0.5` even though
|
||||
"Pekko `1.0.0`" and "Pekko `1.0.5`" *are* binary compatible.
|
||||
|
||||
This is because modules may assume internals changes across module boundaries, for example some feature
|
||||
in Clustering may have required an internals change in Actor, however it is not public API,
|
||||
|
|
@ -78,16 +74,16 @@ If you accidentally mix Pekko versions, for example through transitive
|
|||
dependencies, you might get a warning at run time such as:
|
||||
|
||||
```
|
||||
You are using version 2.6.6 of Pekko, but it appears you (perhaps indirectly) also depend on older versions
|
||||
of related artifacts. You can solve this by adding an explicit dependency on version 2.6.6 of the
|
||||
You are using version 1.0.6 of Pekko, but it appears you (perhaps indirectly) also depend on older versions
|
||||
of related artifacts. You can solve this by adding an explicit dependency on version 1.0.6 of the
|
||||
[pekko-persistence-query] artifacts to your project. Here's a complete collection of detected
|
||||
artifacts: (2.5.3, [pekko-persistence-query]), (2.6.6, [pekko-actor, pekko-cluster]).
|
||||
artifacts: (1.0.3, [pekko-persistence-query]), (1.0.6, [pekko-actor, pekko-cluster]).
|
||||
See also: https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html#mixed-versioning-is-not-allowed
|
||||
```
|
||||
|
||||
The fix is typically to pick the highest Pekko version, and add explicit
|
||||
dependencies to your project as needed. For example, in the example above
|
||||
you might want to add `pekko-persistence-query` dependency for 2.6.6.
|
||||
you might want to add `pekko-persistence-query` dependency for 1.0.6.
|
||||
|
||||
@@@ note
|
||||
|
||||
|
|
|
|||
|
|
@ -311,7 +311,7 @@ Java
|
|||
|
||||
The `org.apache.pekko.pattern.BackoffOnFailureOptions` and `org.apache.pekko.pattern.BackoffOnRestartOptions` can be used to customize the behavior of the back-off supervisor actor.
|
||||
Options are:
|
||||
* `withAutoReset`: The backoff is reset if no failure/stop occurs within the duration. This is the default behaviour with `minBackoff` as default value
|
||||
* `withAutoReset`: The backoff is reset if no failure/stop occurs within the duration. This is the default behavior with `minBackoff` as default value
|
||||
* `withManualReset`: The child must send `BackoffSupervisor.Reset` to its backoff supervisor (parent)
|
||||
* `withSupervisionStrategy`: Sets a custom `OneForOneStrategy` (as each backoff supervisor only has one child). The default strategy uses the `pekko.actor.SupervisorStrategy.defaultDecider` which stops and starts the child on exceptions.
|
||||
* `withMaxNrOfRetries`: Sets the maximum number of retries until the supervisor will give up (`-1` is default which means no limit of retries). Note: This is set on the supervision strategy, so setting a different strategy resets the `maxNrOfRetries`.
|
||||
|
|
|
|||
|
|
@ -14,14 +14,14 @@ wait for intermediate libraries to update.
|
|||
|
||||
## Patch versions
|
||||
|
||||
When releasing a new patch version of Pekko (e.g. 2.5.22), we typically don't
|
||||
When releasing a new patch version of Pekko (e.g. 1.1.0), we typically don't
|
||||
immediately bump the Pekko version in satellite projects.
|
||||
|
||||
The reason for this is this will make it more low-friction for users to update
|
||||
those satellite projects: say their project is on Pekko 2.5.22 and
|
||||
those satellite projects: say their project is on Pekko 1.1.0 and
|
||||
Pekko Management 1.0.0, and we release Pekko Management 1.0.1 (still built with
|
||||
Pekko 2.5.22) and Pekko 2.5.23. They can safely update to Pekko Management 1.0.1
|
||||
without also updating to Pekko 2.5.23, or update to Pekko 2.5.23 without updating
|
||||
Pekko 1.1.0) and Pekko 1.1.1. They can safely update to Pekko Management 1.0.1
|
||||
without also updating to Pekko 1.1.1, or update to Pekko 1.1.1 without updating
|
||||
to Pekko Management 1.0.1.
|
||||
|
||||
When there is reason for a satellite project to upgrade the Pekko patch
|
||||
|
|
@ -29,7 +29,7 @@ version, they are free to do so at any time.
|
|||
|
||||
## Minor versions
|
||||
|
||||
When releasing a new minor version of Pekko (e.g. 2.6.0), satellite projects are
|
||||
When releasing a new minor version of Pekko (e.g. 1.1.0), satellite projects are
|
||||
also usually not updated immediately, but as needed.
|
||||
|
||||
When a satellite project does update to a new minor version of Pekko, it will
|
||||
|
|
|
|||
|
|
@ -1,10 +1,9 @@
|
|||
# Rolling Updates and Versions
|
||||
|
||||
## Pekko upgrades
|
||||
## Apache Pekko Upgrades
|
||||
Pekko supports rolling updates between two consecutive patch versions unless an exception is
|
||||
mentioned on this page. For example updating from 2.5.15 to 2.5.16. Many times
|
||||
mentioned on this page. For example updating from 1.0.0 to 1.0.1. Many times,
|
||||
it is also possible to skip several versions and exceptions to that are also described here.
|
||||
For example it's possible to update from 2.5.14 to 2.5.16 without intermediate 2.5.15.
|
||||
|
||||
It's not supported to have a cluster with more than two different versions. Roll out the first
|
||||
update completely before starting next update.
|
||||
|
|
|
|||
|
|
@ -679,7 +679,6 @@ pekko.remote.artery.large-message-destinations = [
|
|||
"/temp/session-ask-actor*"
|
||||
]
|
||||
```
|
||||
\*NOTE: Support for \* inside of an actor path (ie. /temp/session-ask-actor\*) is only available in 2.6.18+
|
||||
|
||||
This means that all messages sent to the following actors will pass through the dedicated, large messages channel:
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ pekko {
|
|||
As you can see in the example above there are four things you need to add to get started:
|
||||
|
||||
* Change provider from `local`. We recommend using @ref:[Pekko Cluster](cluster-usage.md) over using remoting directly.
|
||||
* Disable artery remoting. Artery is the default remoting implementation since `2.6.0`
|
||||
* Disable artery remoting. Artery is the default remoting implementation in Apache Pekko.
|
||||
* Add host name - the machine you want to run the actor system on; this host
|
||||
name is exactly what is passed to remote systems in order to identify this
|
||||
system and consequently used for connecting back to this system if need be,
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ Scala
|
|||
**completes** when upstream completes and all futures have been completed and all elements have been emitted
|
||||
|
||||
**cancels** when downstream cancels (keep reading)
|
||||
The operator's default behaviour in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behaviour can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
The operator's default behavior in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behavior can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
this will delay downstream cancellation until nested flow's materialization which is then immediately cancelled (with the original cancellation cause).
|
||||
@@@
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ all materialization and what is even worse, unsafely across threads.
|
|||
**completes** when upstream completes and all futures have been completed and all elements have been emitted
|
||||
|
||||
**cancels** when downstream cancels (keep reading)
|
||||
The operator's default behaviour in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behaviour can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
The operator's default behavior in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behavior can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
this will delay downstream cancellation until nested flow's materialization which is then immediately cancelled (with the original cancellation cause).
|
||||
@@@
|
||||
|
|
|
|||
|
|
@ -36,8 +36,8 @@ See @ref:[lazyFlow](lazyFlow.md) for sample.
|
|||
**completes** when upstream completes and all futures have been completed and all elements have been emitted
|
||||
|
||||
**cancels** when downstream cancels (keep reading)
|
||||
The operator's default behaviour in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behaviour can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
The operator's default behavior in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behavior can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
this will delay downstream cancellation until nested flow's materialization which is then immediately cancelled (with the original cancellation cause).
|
||||
@@@
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Deprecated by @ref:[`Flow.lazyFutureFlow`](lazyFutureFlow.md) in combination wit
|
|||
|
||||
## Description
|
||||
|
||||
`fromCompletionStage` was deprecated in Akka 2.6.0 use @ref:[lazyFutureFlow](lazyFutureFlow.md) in combination with @ref:[`prefixAndTail`](../Source-or-Flow/prefixAndTail.md)) instead.
|
||||
`fromCompletionStage` is deprecated, please use @ref:[lazyFutureFlow](lazyFutureFlow.md) in combination with @ref:[`prefixAndTail`](../Source-or-Flow/prefixAndTail.md)) instead.
|
||||
|
||||
Defers creation until a first element arrives.
|
||||
|
||||
|
|
@ -27,8 +27,8 @@ Defers creation until a first element arrives.
|
|||
**completes** when upstream completes and all futures have been completed and all elements have been emitted
|
||||
|
||||
**cancels** when downstream cancels (keep reading)
|
||||
The operator's default behaviour in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behaviour can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
The operator's default behavior in case of downstream cancellation before nested flow materialization (future completion) is to cancel immediately.
|
||||
This behavior can be controlled by setting the [[org.apache.pekko.stream.Attributes.NestedMaterializationCancellationPolicy.PropagateToNested]] attribute,
|
||||
this will delay downstream cancellation until nested flow's materialization which is then immediately cancelled (with the original cancellation cause).
|
||||
@@@
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ When `decideRetry` returns @scala[`None`]@java[`Optional.empty`], no retries wil
|
|||
|
||||
@@@ note
|
||||
|
||||
This API was added in Pekko 2.6.0 and @ref:[may be changed](../../../common/may-change.md) in further patch releases.
|
||||
This API @ref:[may be changed](../../../common/may-change.md) in further patch releases.
|
||||
|
||||
@@@
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ When `decideRetry` returns @scala[`None`]@java[`Optional.empty`], no retries wil
|
|||
|
||||
@@@ note
|
||||
|
||||
This API was added in Pekko 2.6.0 and @ref:[may be changed](../../../common/may-change.md) in further patch releases.
|
||||
This API @ref:[may be changed](../../../common/may-change.md) in further patch releases.
|
||||
|
||||
@@@
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Deprecated by @ref:[`Sink.lazyFutureSink`](lazyFutureSink.md).
|
|||
|
||||
## Description
|
||||
|
||||
`lazyInitAsync` was deprecated in Akka 2.6.0, use @ref:[lazyFutureSink](lazyFutureSink.md) instead.
|
||||
`lazyInitAsync` is deprecated, please use @ref:[lazyFutureSink](lazyFutureSink.md) instead.
|
||||
|
||||
Creates a real `Sink` upon receiving the first element. Internal `Sink` will not be created if there are no elements,
|
||||
because of completion or error.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Deprecated by @ref:[`Source.completionStage`](completionStage.md).
|
|||
|
||||
## Description
|
||||
|
||||
`fromCompletionStage` was deprecated in Akka 2.6.0, use @ref:[completionStage](completionStage.md) instead.
|
||||
`fromCompletionStage` is deprecated, please use @ref:[completionStage](completionStage.md) instead.
|
||||
|
||||
Send the single value of the `CompletionStage` when it completes and there is demand.
|
||||
If the `CompletionStage` completes with `null` stage is completed without emitting a value.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Deprecated by @ref[`Source.future`](future.md).
|
|||
|
||||
## Description
|
||||
|
||||
`fromFuture` was deprecated in Akka 2.6.0, use @ref:[future](future.md) instead.
|
||||
`fromFuture` is deprecated, please use @ref:[future](future.md) instead.
|
||||
|
||||
Send the single value of the `Future` when it completes and there is demand.
|
||||
If the future fails the stream is failed with that exception.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Deprecated by @ref:[`Source.futureSource`](futureSource.md).
|
|||
|
||||
## Description
|
||||
|
||||
`fromFutureSource` was deprecated in Akka 2.6.0, use @ref:[futureSource](futureSource.md) instead.
|
||||
`fromFutureSource` is deprecated, please use @ref:[futureSource](futureSource.md) instead.
|
||||
|
||||
Streams the elements of the given future source once it successfully completes.
|
||||
If the future fails the stream is failed.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Deprecated by @ref:[`Source.completionStageSource`](completionStageSource.md).
|
|||
|
||||
## Description
|
||||
|
||||
`fromSourceCompletionStage` was deprecated in Akka 2.6.0, use @ref:[completionStageSource](completionStageSource.md) instead.
|
||||
`fromSourceCompletionStage` is deprecated, please use @ref:[completionStageSource](completionStageSource.md) instead.
|
||||
|
||||
Streams the elements of an asynchronous source once its given *completion* operator completes.
|
||||
If the *completion* fails the stream is failed with that exception.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Deprecated by @ref:[`Source.lazySource`](lazySource.md).
|
|||
|
||||
## Description
|
||||
|
||||
`lazily` was deprecated in Akka 2.6.0, use @ref:[lazySource](lazySource.md) instead.
|
||||
`lazily` is deprecated, please use @ref:[lazySource](lazySource.md) instead.
|
||||
|
||||
Defers creation and materialization of a `Source` until there is demand.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Deprecated by @ref:[`Source.lazyFutureSource`](lazyFutureSource.md).
|
|||
|
||||
## Description
|
||||
|
||||
`lazilyAsync` was deprecated in Akka 2.6.0, use @ref:[lazyFutureSource](lazyFutureSource.md) instead.
|
||||
`lazilyAsync` is deprecated, please use @ref:[lazyFutureSource](lazyFutureSource.md) instead.
|
||||
|
||||
Defers creation and materialization of a `CompletionStage` until there is demand.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ See also:
|
|||
|
||||
## Example
|
||||
|
||||
In this sample we zip a stream of characters, a stream of numbers and a stream of colours. Into a single `Source`
|
||||
In this sample we zip a stream of characters, a stream of numbers and a stream of colors. Into a single `Source`
|
||||
where each element is a @scala[`Vector`]@java[`List`] of `[character, number, color]`:
|
||||
|
||||
Scala
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ when a WebSocket connection fails due to the HTTP server it's running on going d
|
|||
By using an exponential backoff, we avoid going into a tight reconnect loop, which both gives the HTTP server some time
|
||||
to recover, and it avoids using needless resources on the client side.
|
||||
|
||||
The various restart shapes mentioned all expect an @apidoc[stream.RestartSettings] which configures the restart behaviour.
|
||||
The various restart shapes mentioned all expect an @apidoc[stream.RestartSettings] which configures the restart behavior.
|
||||
Configurable parameters are:
|
||||
|
||||
* `minBackoff` is the initial duration until the underlying stream is restarted
|
||||
|
|
|
|||
|
|
@ -390,7 +390,7 @@ An important aspect of working with streams and actors is understanding a `Mater
|
|||
The materializer is bound to the lifecycle of the @apidoc[actor.ActorRefFactory] it is created from, which in practice will
|
||||
be either an @apidoc[actor.ActorSystem] or @apidoc[ActorContext](actor.ActorContext) (when the materializer is created within an @apidoc[actor.Actor]).
|
||||
|
||||
Tying it to the `ActorSystem` should be replaced with using the system materializer from Pekko 2.6 and on.
|
||||
Tying it to the `ActorSystem` should be replaced with using the system materializer.
|
||||
|
||||
When run by the system materializer the streams will run until the `ActorSystem` is shut down. When the materializer is shut down
|
||||
*before* the streams have run to completion, they will be terminated abruptly. This is a little different than the
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ In some rare cases it may be desirable to do a full cluster shutdown rather than
|
|||
For example, a protocol change where it is simpler to restart the cluster than to make the protocol change
|
||||
backward compatible.
|
||||
|
||||
As of Pekko `2.6.13` it can be signalled that a full cluster shutdown is about to happen and any expensive actions such as:
|
||||
It can be signalled that a full cluster shutdown is about to happen and any expensive actions such as:
|
||||
|
||||
* Cluster sharding rebalances
|
||||
* Moving of Cluster singletons
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ you will likely to see the entire application gets stuck somewhere like this:
|
|||
`PrintActor` is considered non-blocking, however it is not able to proceed with handling the remaining messages,
|
||||
since all the threads are occupied and blocked by the other blocking actors - thus leading to thread starvation.
|
||||
|
||||
In the thread state diagrams below the colours have the following meaning:
|
||||
In the thread state diagrams below the colors have the following meaning:
|
||||
|
||||
* Turquoise - Sleeping state
|
||||
* Orange - Waiting state
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue