Hi all, I am attempting to write a test for http client timeout behaviour.
Here’s my bad test server:
func startBadTestHTTPServer() *httptest.Server {
ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r
*http.Request) {
time.Sleep(60 * time.Second)
> My use case is that I want to pretty print in-memory objects for debug
purposes during testing, and one of the features would be to point out such
cycles as this.
Consider using an existing library for this, for example:
https://github.com/sanity-io/litter
https://github.com/davecgh/go-spe
Hi,
My question is about multiple HTTP client polling an HTTP server randomly
with a PATCH request to update a resource at the server running in front of
MongoDB. The clients poll with their different ids and a valid time in
their request. At the server, I can keep their ids and their differe
On Sat, Nov 14, 2020 at 2:54 AM kev kev wrote:
> Oh right, I seem to not understand why golang is faster in that respect.
> If you can include the precompiled headers and or have an object file
>
>
The key point is that in C++, declarations in header files tend to be
leaky, especially in larger p
Or github.com/kortschak/utter .
This package does an arguably better job at dealing with self-
referencing structures.
On Sat, 2020-11-14 at 03:52 -0800, twp...@gmail.com wrote:
> > My use case is that I want to pretty print in-memory objects for
> debug purposes during testing, and one of the fe
在2020年11月14日星期六 UTC+8 上午3:09:24 写道：
> If I understand what you're trying to do, I'd approach it this way, using
> a generously buffered channel and discarding the extras at the consumer, as
> shown below, instead of at the producer:
>
> result <- c // wait for result to appear
> for len(c) > 0
在2020年11月13日星期五 UTC+8 下午11:19:46 写道：
> On Thu, Nov 12, 2020 at 11:13 PM 陶青云 wrote:
> >
> >
> > It is not a one-length buffered channel. I need to drop because the
> recveiver do heavy work that can't process as quickly as sender.
>
> Don't use channels for this. It's not what they are for.
> On 14 Nov 2020, at 10:28 pm, Amit Saha wrote:
>
> Hi all, I am attempting to write a test for http client timeout behaviour.
> Here’s my bad test server:
>
> func startBadTestHTTPServer() *httptest.Server {
> ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r
>
On Sat, Nov 14, 2020 at 5:43 PM 陶青云 wrote:
> Don't use channels for this. It's not what they are for.
>>
>> Ian
>
> I see some examples using the buffered channel as a job queue. Could you
> give me some advise on this.
>
If you search for terms like "go channel job queue" you'll find examples
t
I don’t think a ring buffer works. At least in a traditional ring buffer the
producer cannot pass the consumer - if the buffer is full the producer blocks
or drops. Trying to ensure the consumer always reads the most recent available
item is better (and more simply) served with a shared hand off
On Sat, Nov 14, 2020 at 7:54 PM Robert Engels wrote:
> I don’t think a ring buffer works. At least in a traditional ring buffer
> the producer cannot pass the consumer - if the buffer is full the producer
> blocks or drops. Trying to ensure the consumer always reads the most recent
> available it
That wasn’t my take on the OPs need. He said the consumer is very expensive -
implying to me they only want to process the latest. If dropping the oldest is
viable you might as well drop all old entries and use the latest.
Pretty common in trading systems with a price feed - in many cases only
On Sat, Nov 14, 2020 at 8:34 PM Robert Engels wrote:
> That wasn’t my take on the OPs need. He said the consumer is very
> expensive - implying to me they only want to process the latest. If
> dropping the oldest is viable you might as well drop all old entries and
> use the latest.
>
The O.P. w
> On 14 Nov 2020, at 20.06, Afriyie Abraham Kwabena
> wrote:
>
> Hi,
>
> My question is about multiple HTTP client polling an HTTP server randomly
> with a PATCH request to update a resource at the server running in front of
> MongoDB. The clients poll with their different ids and a valid
If you read more than write, then you can use a sync.RWMutex an RLock when
reading, Lock when writing.
Kurtis Rader a következőt írta (2020. november 15., vasárnap, 6:13:03
UTC+1):
> On Sat, Nov 14, 2020 at 8:34 PM Robert Engels
> wrote:
>
>> That wasn’t my take on the OPs need. He said the c
15 matches
Mail list logo
