Re: Precheckin job failed to fork JVM during compile

[Donal Evans]

Hi Kirk,

This has been happening intermittently with the latest Liberica JDK8u282 since 
it was released. I worked with the folks at LIberica to reproduce the issue and 
they have a fix which will be included in their next release, sometime in April.

Donal

From: Kirk Lund 
Sent: Thursday, March 25, 2021 1:42 PM
To: dev@geode.apache.org 
Subject: Precheckin job failed to fork JVM during compile

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fbuilds%2F17742data=04%7C01%7Cdoevans%40vmware.com%7C20e8e017a3554007e10608d8efce81a1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637523017517864370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nxaQczcFxF8x%2FyYfy%2FU8OfL7CL2lLNoDpuIjJebJsIg%3Dreserved=0
 core dumped during
compilation of one of the modules.

I believe exit code 134 means that it failed to fork a new Java VM.

I wonder what would cause a test job to be unable to fork a process. It
seems to have forked processes for compiling all of the other modules, so
it's not a persistent problem.

> Task :geode-membership:compileJava
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (methodData.cpp:1252), pid=8491, tid=0x7f1716a78700
#  fatal error: unexpected tag 32
#
# JRE version: OpenJDK Runtime Environment (8.0_282-b08) (build
1.8.0_282-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.282-b08 mixed mode linux-amd64
compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/geode/geode/geode-membership/hs_err_pid8491.log

<<>>

> Task :geode-membership:compileJava
#
# Compiler replay data is saved as:
# /home/geode/geode/geode-membership/replay_pid8491.log
#
# If you would like to submit a bug report, please visit:
#   
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbugreport.java.com%2Fbugreport%2Fcrash.jspdata=04%7C01%7Cdoevans%40vmware.com%7C20e8e017a3554007e10608d8efce81a1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637523017517864370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VLG8CUFcDaO8OpeMtX%2FBPoCNwt1dPOQrOJ%2BC4dTw%2FXE%3Dreserved=0

<<>>

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-membership:compileJava'.
> Compilation failed with exit code 134; see the compiler error output for
details.

Precheckin job failed to fork JVM during compile

[Kirk Lund]

https://concourse.apachegeode-ci.info/builds/17742 core dumped during
compilation of one of the modules.

I believe exit code 134 means that it failed to fork a new Java VM.

I wonder what would cause a test job to be unable to fork a process. It
seems to have forked processes for compiling all of the other modules, so
it's not a persistent problem.

> Task :geode-membership:compileJava
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (methodData.cpp:1252), pid=8491, tid=0x7f1716a78700
#  fatal error: unexpected tag 32
#
# JRE version: OpenJDK Runtime Environment (8.0_282-b08) (build
1.8.0_282-b08)
# Java VM: OpenJDK 64-Bit Server VM (25.282-b08 mixed mode linux-amd64
compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/geode/geode/geode-membership/hs_err_pid8491.log

<<>>

> Task :geode-membership:compileJava
#
# Compiler replay data is saved as:
# /home/geode/geode/geode-membership/replay_pid8491.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp

<<>>

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-membership:compileJava'.
> Compilation failed with exit code 134; see the compiler error output for
details.

Re: [DISCUSS] CODEOWNERS mechanism feedback

[Nabarun Nag]

We will get these approved as soon as possible.

Regards,
Nabarun

From: Mario Ivanac 
Sent: Thursday, March 25, 2021 4:17 AM
To: dev@geode.apache.org 
Subject: Odg: [DISCUSS] CODEOWNERS mechanism feedback

Hi all,

just to remind on this topic.

Could we expand list of CODEOWNERS in some areas that are bottleneck.
For examples I have 2 PR`s that are waiting on review from WAN area for several 
weeks:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6013data=04%7C01%7Cnnag%40vmware.com%7C8118e3d4a0f04955b4c208d8ef7f9bc5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522678650905214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=sP9CgS6ZHrz%2BcfslYxFg7y9%2FzNhZLGV%2BsX5ccjO2N2A%3Dreserved=0
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6048data=04%7C01%7Cnnag%40vmware.com%7C8118e3d4a0f04955b4c208d8ef7f9bc5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522678650905214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=VH1ntlmmHR2fUaNiylYq6LpmGhOBt7UKXNWVTCn919c%3Dreserved=0

BR,
Mario

Šalje: Anthony Baker 
Poslano: 17. ožujka 2021. 18:08
Prima: dev@geode.apache.org 
Predmet: Re: [DISCUSS] CODEOWNERS mechanism feedback

I think for an active, healthy project community we need to balance two things 
that are somewhat oppositional:  make it easy to contribute and ensure the 
project meets the needs of our users for stability and robust behaviors in the 
face of failures.

> On Mar 17, 2021, at 9:45 AM, Jacob Barrett  wrote:
>
>



> My opinion, I think we need some metric by which to quantify the positive 
> impact against the negative impact otherwise the drag this process has on 
> progress may be discouraging to people joining or staying with this community.
>
> -Jake
>

Re: [DISCUSS] removal of experimental Protobuf client/server interface

[Bruce Schuchardt]

I worked on the protobuf client/server interface as long as anyone else but 
still fail to see the value in keeping it in anything but a branch unless 
someone is going to pick it up soon and complete it.

As Dan pointed out, we already have a good interface for storing Json documents 
and we never got beyond that as cache values with the protobuf i/f.  People 
want to store data in Geode in a way that works with queries, delta propagation 
and other advanced features.  That was, and remains, the main problem for this 
interface.  Without that it's not even as good as the current REST interface.

On 3/24/21, 5:06 PM, "Jens Deppe"  wrote:

I was very excited when the protobuf support became available as it allowed 
for the fairly quick development of a Go client. 
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgemfire%2Fgeode-go-clientdata=04%7C01%7Cbruces%40vmware.com%7C1aa78a3a50c44b04d0e008d8ef21e245%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637522276105261607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vxO9PPufoN04%2Frd8oqzrAqIpP0MZHbw828ZXFiuZGFI%3Dreserved=0).
 As Udo already mentioned, removing this functionality reduces our potential 
exposure to new use cases and language bindings. Just because it isn't 'feature 
complete' doesn't mean it isn't useful to someone. In fact, just today, 
somebody reached out regarding the Go binding. 

When considering various popular libraries/frameworks, they all have 
multiple bindings. Some of those are core to the library, but many are 
maintained separately. Having a well-defined protocol for Geode is the first 
step in making that possible.

--Jens

On 3/24/21, 1:11 PM, "Dan Smith"  wrote:

I also worked on the protobuf interface for a little while, although 
not for as long as some of the other folks commenting. I'm ok with removing it. 
I do see some value in leaving stalled/incomplete projects around as bait for 
future developers to pick up - that seems to have worked for redis ;) But if it 
is a maintenance burden lets drop it from develop. Someone can always pick it 
up from the history.

If I recall correctly, one of the big incomplete parts of the project 
is that we hadn't figured out how to serialize user objects efficiently with 
this protocol. The default was to convert PDX objects to JSON. That was about 
as efficient as the existing REST protocol, which also uses json.

-Dan

From: Mike Martell 
Sent: Tuesday, March 23, 2021 4:53 PM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] removal of experimental Protobuf client/server 
interface

As the only remaining member on the CSharpDriver team, I too have an 
attachment to Protobuf. It’s purely technical, however, not emotional. I was 
truly excited about the prospects of a self-describing protocol and had hopes 
for a .NET client talking directly to geode without going through the C++ 
layer. The performance I measured doing puts/gets of a broad range of object 
sizes was at parity with the C++ client. I was truly surprised to see the 
project shelved. But I do understand we had extremely limited functionality not 
even close to an MVP. In hindsight, we should have put all the resources on the 
server side, as the client implementation was almost trivial.

Mike


---
Sent from Workspace ONE 
Boxer

On March 23, 2021 at 3:55:33 PM PDT, Udo Kohlmeyer  
wrote:
Alexander, as you know, the intent for this work was to lower the 
barrier of entry, as the Geode wire protocol is not documented, which makes it 
impossible to contribute any clients in other languages to the project. The 
lack of documentation of this feature did also not help the case.

If no-one else sees ANY benefit of having a self-describing wire 
protocol as part of the project, then you should remove it. But as stated, 
without AND documentation pertaining to the wire protocol for Geode, removing 
the only self-describing protocol with serialization, adopted by many globally, 
will put the barrier of entry of contributing to Geode, outside of Java and 
C++/C# even higher.

In addition, I'm sure that the contributors to the C++/C# client could 
actually benefit in using this protocol.

But I am just a single voice.

--Udo

On 3/24/21, 9:38 AM, "Alexander Murmann"  wrote:

Udo, having worked on Protobuf with you, I share the emotional 
attachment. I 

Odg: [DISCUSS] CODEOWNERS mechanism feedback

[Mario Ivanac]

Hi all,

just to remind on this topic.

Could we expand list of CODEOWNERS in some areas that are bottleneck.
For examples I have 2 PR`s that are waiting on review from WAN area for several 
weeks:

https://github.com/apache/geode/pull/6013
https://github.com/apache/geode/pull/6048

BR,
Mario

Šalje: Anthony Baker 
Poslano: 17. ožujka 2021. 18:08
Prima: dev@geode.apache.org 
Predmet: Re: [DISCUSS] CODEOWNERS mechanism feedback

I think for an active, healthy project community we need to balance two things 
that are somewhat oppositional:  make it easy to contribute and ensure the 
project meets the needs of our users for stability and robust behaviors in the 
face of failures.

> On Mar 17, 2021, at 9:45 AM, Jacob Barrett  wrote:
>
>



> My opinion, I think we need some metric by which to quantify the positive 
> impact against the negative impact otherwise the drag this process has on 
> progress may be discouraging to people joining or staying with this community.
>
> -Jake
>