still errors with that

Another interesting observation: not all the targets error'ed. Only a subset of them did; others went through compilation process fine.

oh.

@fancy-rainbow-17651 : ok, that's highly relevant.

compilation of one of your targets might be crashing the JVM

which... i don't think i've seen in a while/ever

@fancy-rainbow-17651 : time to switch to

-ldebug

maybe.

compile(interval-util:all) failed: Problem launching via NailgunClient(host=u'127.0.0.1', port=59163, workdir='/Users/jack/Development/3sumo') command org.pantsbuild.zinc.Main -log-level info -analysis-cache /Users/jack/Development/3sumo/.pants.d/compile/zinc/252d64521cf9/interval-util.all/current/interval-util.all.analysis -classpath
...
Problem in nailgun protocol with nailgun server at 127.0.0.1:59163: TruncatedHeaderError(u"Failed to read nailgun chunk header (TruncatedRead(u'Expected 5 bytes before socket shutdown, instead received 0’,``)).”,)

-> the nailgun successfully launched, got a port assignment (.pids/lifecycle seems to be fine), connected (nailgun was running), but then failed in a session - likely a crash.

For one of the targets that fail, it would pass if I compile it directly.

that’s a bit odd

another possibility is that a concurrent operation is killing the nailgun out from underneath you due to a distribution or fingerprint mismatch.

-ldebug

would reveal that.

@User uploaded a file: logs from -ldebug

/usr/local/var/jenv/shims/java

i saw there were issue reports ng under

jenv

Ah!

@rough-minister-58256 saw you reported in a twitter ticket, but not upstream

yep heh

for posterity, here were the investigation notes:

@User uploaded a file:

Yup, that does seem to be the culprit. Adding a path to

jvm-distributions

fixed the issue.

Thanks for the help!!

I also see crashes like this when a box is resource constrained

not regularly but for sure in a recent case, we had crashing nailguns and determined that someone had set a long-running process that had slurped all the ram

Ah good to know.

Hello everyone, I'm using pants to build python

pex

files, and I'm curious about the artifact cache. I have a python flask app which I build into

server.pex

and also some management/helper scripts, which I've built on-demand when needed. Now I'm updating my CI to build the main management script

manage.pex

. I do this by adding more targets to

pants binary

, and it works fine -- but it feels unusually slow. Building

server.pex

takes almost 2 minutes, and

manage.pex

which I think should have mostly the same dependencies (maybe one or two extra 3rdparty modules such as

click

and

tabulate

) takes just 10 seconds less. Does this sound normal, or could I be doing something wrong? 🙂

Should I take this to the #pex channel, which I just noticed 😬

seems high to me. where does it spend most of the 2 minutes?

is your CI wiping out the .pants.d folder?

hi. does anyone have a recommendation for managing java dependencies when going with one BUILD file per package? Do developers manually maintain these? How do you deal with dependencies that aren’t obvious at compile time, like from Spring beans, reflection, etc? are these also manually maintained dependencies?

Generally they are manually maintained, especially the non-obvious ones (which you want to push to the _binary normally).

fsqio

has a buildgen that can autogen them if you maintain your repo in a certain way.

buildgen is a godsend, but I doubt it would work with dependencies that aren’t visible in the source file (e.g., those only loaded by reflection)