Re: [go-nuts] Re: Extending deadline for logging

2018-08-17 Thread 'Robert Bartoszynski' via golang-nuts
Not sure what would happen if I set the context to context.Background(),
but I'd have to understand the implications of it really well before I did
something against the grain like that (using context.Background() for
request-specific code).

Yeah, perhaps we'll go with the solution of reserving time for Spanner. I
figure I can find out the different percentiles for how long the Spanner
writes take and then set the amount of time reserved for Spanner
accordingly. It will probably be impossible to guarantee that logs never
get dropped, but we can probably make them exceedingly rare.

On Thu, Aug 16, 2018 at 12:18 AM Dave Cheney  wrote:

> Thinking some more about the problem, I think your solution of reserving
> some of the deadline to handle the spanner log in the error case sounds
> like the best answer. However it does lead to questions like, if you
> reserve n seconds to log to spanner in the error path, and it takes longer
> than n, what happens to the error, is it dropped?
>
> On Thursday, 16 August 2018 14:44:08 UTC+10, Dave Cheney wrote:
>>
>> What would happen if you write the error to spanner with a setting
>> context.Backgrond(), ie, no deadline?
>>
>> On 16 August 2018 at 13:57, Robert Bartoszynski  wrote:
>> > Thanks. Perhaps an alternative would be for me to create a child
>> context
>> > with a deadline of (context - x seconds) and pass that to OtherService,
>> with
>> > the expectation that there should be x seconds left over for the write
>> to
>> > spanner.
>> >
>> > On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote:
>> >>
>> >>
>> >>
>> >> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>> >>>
>> >>> As an example:
>> >>> Client calls MyService with a deadline of 10 seconds.
>> >>> MyService calls OtherService as part of responding. However, the call
>> to
>> >>> OtherService times out due to the deadline in 10 seconds.
>> >>> MyService tries to log the error to Spanner; but it's still using
>> that
>> >>> context deadline which expired.
>> >>>
>> >>> Is there a way to get a new context with an extended deadline? Are
>> there
>> >>> any issues with that approach?
>> >>
>> >>
>> >> Sure, just call context.WithDeadline(context.Background()) and use
>> that
>> >> instead
>> >>
>> >>  The difficulty is you want the deadline of this new context to live
>> >> beyond its parent. Logically it feels like this new context is
>> subordinate
>> >> to the previous, but by design we've said that the new context is
>> _not_
>> >> subordinate -- the deadline does not apply to it. I think you need to
>> >> address this incongruousness before proceeding.
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com
>> wrote:
>> 
>>  I'm working on a service that write some log info to spanner when
>> it's
>>  done responding to a request.
>>  However, the service uses the context's deadline to write to
>> spanner, so
>>  if the deadline expires due to some long running RPC, the write to
>> spanner
>>  fails (because the deadline expired), and we don't get any log info.
>> 
>>  What's the best practice for dealing with this situation?
>> >>
>> >> --
>> >> You received this message because you are subscribed to a topic in the
>> >> Google Groups "golang-nuts" group.
>> >> To unsubscribe from this topic, visit
>> >> https://groups.google.com/d/topic/golang-nuts/TUicHyvYNX0/unsubscribe.
>>
>> >> To unsubscribe from this group and all its topics, send an email to
>> >> golang-nuts+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/TUicHyvYNX0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Extending deadline for logging

2018-08-16 Thread Dave Cheney
Thinking some more about the problem, I think your solution of reserving 
some of the deadline to handle the spanner log in the error case sounds 
like the best answer. However it does lead to questions like, if you 
reserve n seconds to log to spanner in the error path, and it takes longer 
than n, what happens to the error, is it dropped?

On Thursday, 16 August 2018 14:44:08 UTC+10, Dave Cheney wrote:
>
> What would happen if you write the error to spanner with a setting 
> context.Backgrond(), ie, no deadline? 
>
> On 16 August 2018 at 13:57, Robert Bartoszynski  wrote: 
> > Thanks. Perhaps an alternative would be for me to create a child context 
> > with a deadline of (context - x seconds) and pass that to OtherService, 
> with 
> > the expectation that there should be x seconds left over for the write 
> to 
> > spanner. 
> > 
> > On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote: 
> >> 
> >> 
> >> 
> >> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote: 
> >>> 
> >>> As an example: 
> >>> Client calls MyService with a deadline of 10 seconds. 
> >>> MyService calls OtherService as part of responding. However, the call 
> to 
> >>> OtherService times out due to the deadline in 10 seconds. 
> >>> MyService tries to log the error to Spanner; but it's still using that 
> >>> context deadline which expired. 
> >>> 
> >>> Is there a way to get a new context with an extended deadline? Are 
> there 
> >>> any issues with that approach? 
> >> 
> >> 
> >> Sure, just call context.WithDeadline(context.Background()) and use that 
> >> instead 
> >> 
> >>  The difficulty is you want the deadline of this new context to live 
> >> beyond its parent. Logically it feels like this new context is 
> subordinate 
> >> to the previous, but by design we've said that the new context is _not_ 
> >> subordinate -- the deadline does not apply to it. I think you need to 
> >> address this incongruousness before proceeding. 
> >> 
> >>> 
> >>> 
> >>> 
> >>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com 
> wrote: 
>  
>  I'm working on a service that write some log info to spanner when 
> it's 
>  done responding to a request. 
>  However, the service uses the context's deadline to write to spanner, 
> so 
>  if the deadline expires due to some long running RPC, the write to 
> spanner 
>  fails (because the deadline expired), and we don't get any log info. 
>  
>  What's the best practice for dealing with this situation? 
> >> 
> >> -- 
> >> You received this message because you are subscribed to a topic in the 
> >> Google Groups "golang-nuts" group. 
> >> To unsubscribe from this topic, visit 
> >> https://groups.google.com/d/topic/golang-nuts/TUicHyvYNX0/unsubscribe. 
> >> To unsubscribe from this group and all its topics, send an email to 
> >> golang-nuts+unsubscr...@googlegroups.com. 
> >> For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Extending deadline for logging

2018-08-15 Thread Dave Cheney
What would happen if you write the error to spanner with a setting
context.Backgrond(), ie, no deadline?

On 16 August 2018 at 13:57, Robert Bartoszynski  wrote:
> Thanks. Perhaps an alternative would be for me to create a child context
> with a deadline of (context - x seconds) and pass that to OtherService, with
> the expectation that there should be x seconds left over for the write to
> spanner.
>
> On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote:
>>
>>
>>
>> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>>>
>>> As an example:
>>> Client calls MyService with a deadline of 10 seconds.
>>> MyService calls OtherService as part of responding. However, the call to
>>> OtherService times out due to the deadline in 10 seconds.
>>> MyService tries to log the error to Spanner; but it's still using that
>>> context deadline which expired.
>>>
>>> Is there a way to get a new context with an extended deadline? Are there
>>> any issues with that approach?
>>
>>
>> Sure, just call context.WithDeadline(context.Background()) and use that
>> instead
>>
>>  The difficulty is you want the deadline of this new context to live
>> beyond its parent. Logically it feels like this new context is subordinate
>> to the previous, but by design we've said that the new context is _not_
>> subordinate -- the deadline does not apply to it. I think you need to
>> address this incongruousness before proceeding.
>>
>>>
>>>
>>>
>>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:

 I'm working on a service that write some log info to spanner when it's
 done responding to a request.
 However, the service uses the context's deadline to write to spanner, so
 if the deadline expires due to some long running RPC, the write to spanner
 fails (because the deadline expired), and we don't get any log info.

 What's the best practice for dealing with this situation?
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/TUicHyvYNX0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Extending deadline for logging

2018-08-15 Thread 'Robert Bartoszynski' via golang-nuts
Thanks. Perhaps an alternative would be for me to create a child context
with a deadline of (context - x seconds) and pass that to OtherService,
with the expectation that there should be x seconds left over for the write
to spanner.

On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney  wrote:

>
>
> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>>
>> As an example:
>> Client calls MyService with a deadline of 10 seconds.
>> MyService calls OtherService as part of responding. However, the call to
>> OtherService times out due to the deadline in 10 seconds.
>> MyService tries to log the error to Spanner; but it's still using that
>> context deadline which expired.
>>
>> Is there a way to get a new context with an extended deadline? Are there
>> any issues with that approach?
>>
>
> Sure, just call context.WithDeadline(context.Background()) and use that
> instead
>
>  The difficulty is you want the deadline of this new context to live
> beyond its parent. Logically it feels like this new context is subordinate
> to the previous, but by design we've said that the new context is _not_
> subordinate -- the deadline does not apply to it. I think you need to
> address this incongruousness before proceeding.
>
>
>>
>>
>> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:
>>>
>>> I'm working on a service that write some log info to spanner when it's
>>> done responding to a request.
>>> However, the service uses the context's deadline to write to spanner, so
>>> if the deadline expires due to some long running RPC, the write to spanner
>>> fails (because the deadline expired), and we don't get any log info.
>>>
>>> What's the best practice for dealing with this situation?
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/TUicHyvYNX0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Extending deadline for logging

2018-08-15 Thread Dave Cheney


On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>
> As an example:
> Client calls MyService with a deadline of 10 seconds.
> MyService calls OtherService as part of responding. However, the call to 
> OtherService times out due to the deadline in 10 seconds.
> MyService tries to log the error to Spanner; but it's still using that 
> context deadline which expired.
>
> Is there a way to get a new context with an extended deadline? Are there 
> any issues with that approach?
>

Sure, just call context.WithDeadline(context.Background()) and use that 
instead

 The difficulty is you want the deadline of this new context to live beyond 
its parent. Logically it feels like this new context is subordinate to the 
previous, but by design we've said that the new context is _not_ 
subordinate -- the deadline does not apply to it. I think you need to 
address this incongruousness before proceeding.
 

>
>
> On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:
>>
>> I'm working on a service that write some log info to spanner when it's 
>> done responding to a request. 
>> However, the service uses the context's deadline to write to spanner, so 
>> if the deadline expires due to some long running RPC, the write to spanner 
>> fails (because the deadline expired), and we don't get any log info.
>>
>> What's the best practice for dealing with this situation?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Extending deadline for logging

2018-08-15 Thread rbz via golang-nuts
As an example:
Client calls MyService with a deadline of 10 seconds.
MyService calls OtherService as part of responding. However, the call to 
OtherService times out due to the deadline in 10 seconds.
MyService tries to log the error to Spanner; but it's still using that 
context deadline which expired.

Is there a way to get a new context with an extended deadline? Are there 
any issues with that approach?


On Tuesday, August 14, 2018 at 1:25:47 PM UTC-7, r...@google.com wrote:
>
> I'm working on a service that write some log info to spanner when it's 
> done responding to a request. 
> However, the service uses the context's deadline to write to spanner, so 
> if the deadline expires due to some long running RPC, the write to spanner 
> fails (because the deadline expired), and we don't get any log info.
>
> What's the best practice for dealing with this situation?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.