Skip to content
This repository was archived by the owner on Jan 25, 2022. It is now read-only.

Correct request timeout behavior in VCAP::Stager::Client::EmAware#stage#1

Closed
nota-ja wants to merge 1 commit intocloudfoundry-attic:masterfrom
nota-ja:pr-correct-request-timeout-behavior
Closed

Correct request timeout behavior in VCAP::Stager::Client::EmAware#stage#1
nota-ja wants to merge 1 commit intocloudfoundry-attic:masterfrom
nota-ja:pr-correct-request-timeout-behavior

Conversation

@nota-ja
Copy link

@nota-ja nota-ja commented May 19, 2013

In the stage method, Stager's NATS client should timeout to unsubscribe
the subscription made by its request, no matter how many number of
responses received to the request.

If it does not unsubscribe, unused subscriptions increases monotonically
both in the NATS server and client. They may cause a memory problem.

The present implementation does not set:

  • :max option for @nats.request method
  • :expected option for @nats.timeout method

If the :max option is set, the subscription generated for the request
will be unsubscribed when the specified number of responses are
received, even when it is before the timeout. But the present
implementation does not use this option.

The :expected option is used to cancel timeout if the given number
of responses are received in the timeout period. The default value of
:expected option is 1. So with the present implementation, timeout is
cancelled when a response has been received.

Because of the reasons in the previous two paragraphs, a subscription
generated by a request will remain if a response is received during
the period of timeout.

There are two methods to correct the situation.

  1. set :max option for @nats.request method
  2. set :expected option for @nats.timeout method to very large value

This commit amend the issue by setting :max to 1. Thereby the
subscriptions made by NATS requests will be unsubscribed when the
first response is received, or when it is timed out if there is no
response.

In the stage method, Stager's NATS client should timeout to unsubscribe
the subscription made by its request, no matter how many number of
responses received to the request.

If it does not unsubscribe, unused subscriptions increases monotonically
both in the NATS server and client. They may cause a memory problem.

The present implementation does not set:
- :max option for @nats.request method
- :expected option for @nats.timeout method

If the :max option is set, the subscription generated for the request
will be unsubscribed when the specified number of responses are
received, even when it is before the timeout. But the present
implementation does not use this option.

The :expected option is used to *cancel* timeout if the given number
of responses are received in the timeout period. The default value of
:expected option is 1. So with the present implementation, timeout is
cancelled when a response has been received.

Because of the reasons in the previous two paragraphs, a subscription
generated by a request will remain if a response is received during
the period of timeout.

There are two methods to correct the situation.
1) set :max option for @nats.request method
2) set :expected option for @nats.timeout method to very large value

This commit amend the issue by setting :max to 1. Thereby the
subscriptions made by NATS requests will be unsubscribed when the
first response is received, or when it is timed out if there is no
response.
@nota-ja
Copy link
Author

nota-ja commented Jun 20, 2013

Hi,

Is anyone here?

@RobDay-Reynolds
Copy link

@nota-ja This repository was deprecated and we are not supporting it anymore. Please feel free to fork it, but we will not be actively maintaining it.

Thanks!
@monkeyherder & @mariash

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants