On 09/11/17 19:17, Michael Vorburger wrote:
> BTW: How will these RPC Java interfaces look like in the future Binding
> v2? Hopefully not Future anymore...
Nope. And since we have (kind of) learned a lesson, baseline APIs take a
completion lambda argument, which can be bridged to any future-like
c
On Thu, Nov 9, 2017 at 12:40 PM, Stephen Kitt wrote:
> On Thu, 9 Nov 2017 00:48:47 +0100
> Michael Vorburger wrote:
> > while starting to work on
> > https://jira.opendaylight.org/browse/INFRAUTILS-19, I've realized
> > something I wanted to run by you / anyone else interested on list
> > before
On Wed, Nov 8, 2017 at 7:57 PM, Robert Varga wrote:
> On 08/11/17 19:43, Michael Vorburger wrote:
> > Hello,
> >
> > I'm trying to understand what the intention of the original designers
> > who wrote this was re. what to do with the Future returned by RpcService
> > implementations.. as it's not
On Thu, 9 Nov 2017 12:40:00 +0100
Stephen Kitt wrote:
> On Thu, 9 Nov 2017 00:48:47 +0100
> Michael Vorburger wrote:
> > Tomorrow, projects wishing to expose metrics will get use
> > dropwizard.metrics by way of an (upcoming) infrautils.metrics
> > dependency anyway, instead of a direct dependenc
On Thu, Nov 9, 2017 at 11:45 AM, Stephen Kitt wrote:
> Exactly, that’s what I was alluding to with “the lack of swap probably
> doesn’t help” ;-). We should really configure VMs with a small amount
> of swap, it can save the kernel in tricky situations...
>
> On Thu, 9 Nov 2017 01:47:08 -0800
> A
On Thu, 9 Nov 2017 00:48:47 +0100
Michael Vorburger wrote:
> while starting to work on
> https://jira.opendaylight.org/browse/INFRAUTILS-19, I've realized
> something I wanted to run by you / anyone else interested on list
> before I raise respective Gerrits:
>
> In https://git.opendaylight.org/g
Exactly, that’s what I was alluding to with “the lack of swap probably
doesn’t help” ;-). We should really configure VMs with a small amount
of swap, it can save the kernel in tricky situations...
On Thu, 9 Nov 2017 01:47:08 -0800
Anil Vishnoi wrote:
> I suspect you might hit it again if you run
I suspect you might hit it again if you run it a bit longer because of this
[Thu Nov 2 05:58:08 2017] Free swap = 0kB
[Thu Nov 2 05:58:08 2017] Total swap = 0kB
On Thu, Nov 9, 2017 at 1:39 AM, Stephen Kitt wrote:
> On Thu, 9 Nov 2017 10:28:14 +0100
> Robert Varga wrote:
> > On 02/11/17 23:
On Thu, 9 Nov 2017 10:28:14 +0100
Robert Varga wrote:
> On 02/11/17 23:02, Luis Gomez wrote:
> > 1) JVM does not kill itself, the OS does instead after the java
> > process grows to 3.7G in a VM of 4G RAM (note Xmx is set to 2G but
> > still the jvm goes far beyond that).
>
> Indicates this li
On 03/11/17 01:37, Michael Vorburger wrote:
>
> quickly wrote ThreadExplosion.java just attached to NETVIRT-974 to
> convince myself that's unlikely it (because that would "just" cause an
> "java.lang.OutOfMemoryError: unable to create new native thread", but
> not what you're seeing here)..
De
On 02/11/17 23:02, Luis Gomez wrote:
> 1) JVM does not kill itself, the OS does instead after the java process grows
> to 3.7G in a VM of 4G RAM (note Xmx is set to 2G but still the jvm goes far
> beyond that).
Indicates this lies out side of heap -- check thread count.
Bye,
Robert
signatur
Reading through the mail thread, I doubt that OS is killing the JVM, it's
definitely a native OOM, where JVM is trying to do malloc/calloc and it
does not find the memory and malloc crashes the JVM process(seg fault). I
have seen many native OOM issue with 32 bit JVM because of it's 4gig
virtual ad
12 matches
Mail list logo
