; 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.
> To view this discussion on the web visit
> https://grou
der heavy load (and clients
>> see connection reset by peer)
>>
>> Does anyone know a way of getting current open connections?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from
There are several conditions that bypass recover. Another example is "fatal
error: concurrent map read and map write". The error messages typically
start with "fatal error" and represent a non recoverable exception in the
run time rather than a user defined condition.
I don't know the official ter
> I believe https://golang.org/pkg/encoding/json/#Decoder.Buffered was
added for this purpose.
I just caught on that this method is exactly what you showed in the
original message. I guess my input can be reduced to "I think that's your
only option when using the decoder".
I do think you've corre
> For example, the error returned may show : "*invalid character 'G'
looking for beginning of value*". But you can't see the original message.
I believe https://golang.org/pkg/encoding/json/#Decoder.Buffered was added
for this purpose. For example, https://play.golang.org/p/yAn2fypIELc
> 1- I'm n
> Are requests sent serially ... so that other concurrent requests to the
same host are blocked
When sending requests using HTTP/1, each connection will handle only one
request at a time except when using pipelining. When sending requests using
HTTP/2, each connection may manage any number of req
A few of us had a very short discussion on the subject here:
https://groups.google.com/forum/#!topic/golang-nuts/rjYdaFM5OBw
Almost all go code I've seen that requires an HTTP client takes an
`*http.Client` as one of the parameters. This doesn't leave consumers with
many other options than to leve
> You can have a filter which increments the counter and records for each
request from the user and kicks him/her when the limit is crossed.
We're actually interested in this problem from the other direction. When
making an outbound HTTP request we want to limit the number of times (or
the maxi
Unfortunately, neither the http. Client nor the *http. Request expose a
reference to the underlying connection such that you could implement that
behaviour. At least, that's what I've found when trying to do this as well.
One possible strategy we've considered is implementing a wrapper around the
If I understand correctly, you're describing a simplified version of
https://twistedmatrix.com/documents/current/web/howto/using-twistedweb.html
which
provides the concept of "path" by having a system that generates a graph of
resource nodes than can be rendered. Routing to any specific endpoint is
>>>> Given that said, the program does not nothing but receiving the packet
>>>> at this moment. Any actual processing of the packet in the same thread
>>>> significantly hurt the rate. Besides spinning multiple thread to handle the
>>>> actual work, anyt
Before we put the focus on criticism of the OP's code organisation, it's
well worth investigating the likely code bug first.
>but when I use var m storage.ModelInterface and then call a member
function of the interface (SetName) Go panics because nil pointer
dereference
Based on this problem descr
> Any actual processing of the packet in the same thread significantly
hurt the rate
> offload the actual packet processing to a different goroutine
As Rajanikanth points out, you'll need to put your work in other goroutines
to make use of your other cores for processing them. One goroutine per
> can only handle up to 250Mbps-ish traffic
I'm not familiar with gopacket, but I have seen multiple occasions where
logging to a file or stdout became a bottleneck. Your code snippet is
logging on every packet which seems excessive. Try logging with less
frequency and, if using stdout, consider u
I'm speculating a bit here until I can dig back into the listener stack,
but at least one variable you can tweak is the connection keep alive. On
the surface, limit listener appears to gate on the socket accept call. I
feel it is an important distinction because it limits the listener and not
the r
> To try to postpone the exit of a program after a critical error to me
implies a much more complex testing and validation process that has
identified all the shared state in the program and verified that it is
correct in the case that a panic is caught
There's an implicit argument here that the p
On Mon, Apr 24, 2017, 21:31 Sam Whited wrote:
> On Mon, Apr 24, 2017 at 6:31 PM, Dan Kortschak
> wrote:
> > We (gonum) would extend the security exception to include scientific
> > code; there are far too many peer reviewed works that depend on code
> > that will blithely continue after an error
> If so, then how should I raise unrecoverable error, if I really know that
it is unrecoverable?
I don't believe you can ever know whether an error in your library is truly
unrecoverable by the process executing the code. As a someone writing and
operating the process, I'd expect a library to prov
I'd say that recover() is not a problem but, instead, a symptom of panic()
being available to developers. I'd flip the title and say panic() should be
considered harmful. To quote from
https://blog.golang.org/defer-panic-and-recover :
> The process continues up the stack until all functions in the
Alternatively, if you are walking an AST and only interested in the
exported names then you can use
https://golang.org/pkg/go/ast/#PackageExports . It will filter your tree to
only elements that are exported before you begin traversal.
As to your specific case of determining if a type used in a me
Having used go-swagger (https://github.com/go-swagger/go-swagger) at one
point, I'd say that these YAML generators are possibly useful for
generating documentation from your code. One pain point of the
documentation generators, though, is that most require that I create and
maintain code objects ex
t, Mar 4, 2017 at 4:16 PM John Kemp wrote:
> AFAIK, there is (still?) no out-of-the-box support for gzip.
>
> See, for example, https://github.com/NYTimes/gziphandler
>
> - johnk
>
> > On Mar 4, 2017, at 5:11 PM, Kevin Conway
> wrote:
> >
> > I'm running
I'm running a go 1.7 HTTP server. One of my clients is applying gzip to the
POST body of their request and applying the appropriate content-encoding
header. The current server implementation in go, unlike the client, does
not appear to automatically handle decompression of the body. This is
causing
If your project exposes one interface and many implementations of it then
I'd consider it reasonable to have your interface in the top level package
and a subpackage for each implementation.
On Fri, Feb 17, 2017, 02:33 Luca Looz wrote:
> I'm starting now the project and i'm seeking advices on ho
> How would I swap out a http.Client that is required by a third-party
library with a another that supports, say retries with exponential back-off?
I'd suggest looking at http.Transport and http.RoundTripper [
https://golang.org/pkg/net/http/#RoundTripper]. The docs explicitly forbid
using RoundTr
Not sure exactly how to describe this issue or the right words to use when
talking about some of the concepts. Here's a best effort.
Given a type T that implements interfaces A1 and A2, T is an acceptable
input for any function that requires an A1 or A2 as input. Given A1 and A2
are identical in d
26 matches
Mail list logo
