Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Permit copy for TestExecutor AsyncContextMap #1675

Merged
merged 1 commit into from
Jul 19, 2021
Merged

Permit copy for TestExecutor AsyncContextMap #1675

merged 1 commit into from
Jul 19, 2021

Conversation

bondolo
Copy link
Contributor

@bondolo bondolo commented Jul 16, 2021

As observed by @chemicL

Motivation:
The TestExecutor was recently enhanced to install an invalid
AsyncContextMap when executing Runnable tasks to check for tasks
which did not properly save/restore the appropriate async context. The
invalid map should allow itself to be copied, producing an empty map,
for usages which want to initiate a new subscribe operation.
Modifications:
copy() returns a new empty map rather than generating an exception.
Result:
Now possible to subscribe() within a Runnable without providing an
AsyncContextMap.

@bondolo bondolo added the bug Something isn't working label Jul 16, 2021
@bondolo bondolo self-assigned this Jul 16, 2021
@bondolo
Permit copy for TestExecutor AsyncContextMap
97dd4b5 
Motivation:
The TestExecutor was recently enhanced to install an invalid
AsyncContextMap when executing Runnable tasks to check for tasks
which did not properly save/restore the appropriate async context. The
invalid map should allow itself to be copied, for usages which want to
initiate a new subscribe operation.
Modifications:
copy() returns the same map rather than generating an exception.
Result:
Now possible to subscribe() within a Runnable without providing an
`AsyncContextMap`.
@bondolo bondolo force-pushed the TestExecutor-copy branch from 890574d to 97dd4b5 Compare July 19, 2021 16:57
@bondolo bondolo merged commit f84d9d4 into apple:main Jul 19, 2021
@bondolo bondolo deleted the TestExecutor-copy branch July 19, 2021 22:59
bondolo added a commit to bondolo/servicetalk that referenced this pull request Jul 27, 2021
@bondolo
TestExecutor Runnable preserve AsyncContextMap
f6a5f5a 
Motivation:
The earlier PR apple#1662 (and followon apple#1675),  were intended to resolve
issues with handling of AsyncContextMap and
`TestExecutor.execute(Runnable)` but the nature of the problem was
misunderstood. In those cases the observed problem was that causing
tasks to execute using `TestExecutor.executeNextTask()` from a
different thread than that which enqueued the task resulted in a
new empty AsyncContextMap being used rather than the correct
AsyncContextMap. The solution in apple#1662 was intended to detect the
case where the map was not correctly being set by the wrapping of
the Subscription or Subscriber in the operator chain. It missed
that the behavior of TestExecutor was itself inconsistent with other
ServiceTalk executors. Executors are supposed to propagate the
AsyncContextMap from the thread invoking `Executor.execute()` to
the thread which executes the `Runnable`. This behavior was missing
in TestExecutor which originally did not set the AsyncContextMap and
after apple#1662 set the map to an intentionally invalid map.
Modifications:
TestExecutor captures the active `AsyncContextMap` at task creation and
when the task is eventually executed the `Runnable` is invoked with
the same map active.
Result:
TestExecutor behavior matches other executors.
@bondolo bondolo mentioned this pull request Jul 27, 2021
Merged
bondolo added a commit to bondolo/servicetalk that referenced this pull request Jul 27, 2021
@bondolo
TestExecutor Runnable preserve AsyncContextMap
cea5373 
Motivation:
The earlier PR apple#1662 (and followon apple#1675),  were intended to resolve
issues with handling of AsyncContextMap and
`TestExecutor.execute(Runnable)` but the nature of the problem was
misunderstood. In those cases the observed problem was that causing
tasks to execute using `TestExecutor.executeNextTask()` from a
different thread than that which enqueued the task resulted in a
new empty AsyncContextMap being used rather than the correct
AsyncContextMap. The solution in apple#1662 was intended to detect the
case where the map was not correctly being set by the wrapping of
the Subscription or Subscriber in the operator chain. It missed
that the behavior of TestExecutor was itself inconsistent with other
ServiceTalk executors. Executors are supposed to propagate the
AsyncContextMap from the thread invoking `Executor.execute()` to
the thread which executes the `Runnable`. This behavior was missing
in TestExecutor which originally did not set the AsyncContextMap and
after apple#1662 set the map to an intentionally invalid map.
Modifications:
TestExecutor captures the active `AsyncContextMap` at task creation and
when the task is eventually executed the `Runnable` is invoked with
the same map active.
Result:
TestExecutor behavior matches other executors.
bondolo added a commit that referenced this pull request Jul 28, 2021
@bondolo
TestExecutor Runnable preserve AsyncContextMap (#1699)
bddc63d 
Motivation:
The earlier PR #1662 (and followon #1675),  were intended to resolve
issues with handling of AsyncContextMap and
`TestExecutor.execute(Runnable)` but the nature of the problem was
misunderstood. In those cases the observed problem was that causing
tasks to execute using `TestExecutor.executeNextTask()` from a
different thread than that which enqueued the task resulted in a
new empty AsyncContextMap being used rather than the correct
AsyncContextMap. The solution in #1662 was intended to detect the
case where the map was not correctly being set by the wrapping of
the Subscription or Subscriber in the operator chain. It missed
that the behavior of TestExecutor was itself inconsistent with other
ServiceTalk executors. Executors are supposed to propagate the
AsyncContextMap from the thread invoking `Executor.execute()` to
the thread which executes the `Runnable`. This behavior was missing
in `TestExecutor` which originally did not set the `AsyncContextMap`
and after #1662 set the map to an intentionally invalid map.
Modifications:
`TestExecutor` now captures the active `AsyncContextMap` at task 
creation and when the task is eventually executed the task `Runnable` 
is invoked with the same map active.
Result:
`TestExecutor` behavior now matches other executors.
bondolo added a commit to bondolo/servicetalk that referenced this pull request Jul 28, 2021
@bondolo
Permit copy for TestExecutor AsyncContextMap (apple#1675)
cc76f15 
Motivation:
The `TestExecutor` was recently enhanced to install an invalid
`AsyncContextMap` when executing `Runnable` tasks to check for tasks
which did not properly save/restore the appropriate async context. The
invalid map should allow itself to be copied, producing an empty map,
for usages which want to initiate a new subscribe operation.
Modifications:
`copy()` returns a new empty map rather than generating an exception.
Result:
Now possible to subscribe() within a `Runnable` without providing an
`AsyncContextMap`.
bondolo added a commit to bondolo/servicetalk that referenced this pull request Jul 28, 2021
@bondolo
TestExecutor Runnable preserve AsyncContextMap (apple#1699)
8137442 
Motivation:
The earlier PR apple#1662 (and followon apple#1675),  were intended to resolve
issues with handling of AsyncContextMap and
`TestExecutor.execute(Runnable)` but the nature of the problem was
misunderstood. In those cases the observed problem was that causing
tasks to execute using `TestExecutor.executeNextTask()` from a
different thread than that which enqueued the task resulted in a
new empty AsyncContextMap being used rather than the correct
AsyncContextMap. The solution in apple#1662 was intended to detect the
case where the map was not correctly being set by the wrapping of
the Subscription or Subscriber in the operator chain. It missed
that the behavior of TestExecutor was itself inconsistent with other
ServiceTalk executors. Executors are supposed to propagate the
AsyncContextMap from the thread invoking `Executor.execute()` to
the thread which executes the `Runnable`. This behavior was missing
in `TestExecutor` which originally did not set the `AsyncContextMap`
and after apple#1662 set the map to an intentionally invalid map.
Modifications:
`TestExecutor` now captures the active `AsyncContextMap` at task 
creation and when the task is eventually executed the task `Runnable` 
is invoked with the same map active.
Result:
`TestExecutor` behavior now matches other executors.
@bondolo
Copy link
Contributor Author

bondolo commented Jul 28, 2021

0.41 (cc76f15)

bondolo added a commit to bondolo/servicetalk that referenced this pull request Aug 27, 2021
@bondolo
Permit copy for TestExecutor AsyncContextMap (apple#1675)
21922ca 
Motivation:
The `TestExecutor` was recently enhanced to install an invalid
`AsyncContextMap` when executing `Runnable` tasks to check for tasks
which did not properly save/restore the appropriate async context. The
invalid map should allow itself to be copied, producing an empty map,
for usages which want to initiate a new subscribe operation.
Modifications:
`copy()` returns a new empty map rather than generating an exception.
Result:
Now possible to subscribe() within a `Runnable` without providing an
`AsyncContextMap`.
bondolo added a commit to bondolo/servicetalk that referenced this pull request Aug 27, 2021
@bondolo
TestExecutor Runnable preserve AsyncContextMap (apple#1699)
a035a82 
Motivation:
The earlier PR apple#1662 (and followon apple#1675),  were intended to resolve
issues with handling of AsyncContextMap and
`TestExecutor.execute(Runnable)` but the nature of the problem was
misunderstood. In those cases the observed problem was that causing
tasks to execute using `TestExecutor.executeNextTask()` from a
different thread than that which enqueued the task resulted in a
new empty AsyncContextMap being used rather than the correct
AsyncContextMap. The solution in apple#1662 was intended to detect the
case where the map was not correctly being set by the wrapping of
the Subscription or Subscriber in the operator chain. It missed
that the behavior of TestExecutor was itself inconsistent with other
ServiceTalk executors. Executors are supposed to propagate the
AsyncContextMap from the thread invoking `Executor.execute()` to
the thread which executes the `Runnable`. This behavior was missing
in `TestExecutor` which originally did not set the `AsyncContextMap`
and after apple#1662 set the map to an intentionally invalid map.
Modifications:
`TestExecutor` now captures the active `AsyncContextMap` at task 
creation and when the task is eventually executed the task `Runnable` 
is invoked with the same map active.
Result:
`TestExecutor` behavior now matches other executors.
bondolo added a commit that referenced this pull request Aug 27, 2021
@bondolo
Permit copy for TestExecutor AsyncContextMap (#1675)
a64d009 
Motivation:
The `TestExecutor` was recently enhanced to install an invalid
`AsyncContextMap` when executing `Runnable` tasks to check for tasks
which did not properly save/restore the appropriate async context. The
invalid map should allow itself to be copied, producing an empty map,
for usages which want to initiate a new subscribe operation.
Modifications:
`copy()` returns a new empty map rather than generating an exception.
Result:
Now possible to subscribe() within a `Runnable` without providing an
`AsyncContextMap`.
bondolo added a commit that referenced this pull request Aug 27, 2021
@bondolo
TestExecutor Runnable preserve AsyncContextMap (#1699)
a6391fe 
Motivation:
The earlier PR #1662 (and followon #1675),  were intended to resolve
issues with handling of AsyncContextMap and
`TestExecutor.execute(Runnable)` but the nature of the problem was
misunderstood. In those cases the observed problem was that causing
tasks to execute using `TestExecutor.executeNextTask()` from a
different thread than that which enqueued the task resulted in a
new empty AsyncContextMap being used rather than the correct
AsyncContextMap. The solution in #1662 was intended to detect the
case where the map was not correctly being set by the wrapping of
the Subscription or Subscriber in the operator chain. It missed
that the behavior of TestExecutor was itself inconsistent with other
ServiceTalk executors. Executors are supposed to propagate the
AsyncContextMap from the thread invoking `Executor.execute()` to
the thread which executes the `Runnable`. This behavior was missing
in `TestExecutor` which originally did not set the `AsyncContextMap`
and after #1662 set the map to an intentionally invalid map.
Modifications:
`TestExecutor` now captures the active `AsyncContextMap` at task 
creation and when the task is eventually executed the task `Runnable` 
is invoked with the same map active.
Result:
`TestExecutor` behavior now matches other executors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Scottmitch Scottmitch Scottmitch approved these changes

@idelpivnitskiy idelpivnitskiy Awaiting requested review from idelpivnitskiy

@chemicL chemicL Awaiting requested review from chemicL

@tkountis tkountis Awaiting requested review from tkountis

Assignees

@bondolo bondolo

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@bondolo @chemicL @tkountis @Scottmitch