Should print id of daemon that is processing the request

[famod]

Yesterday, the daemon seemed stuck while builing Quarkus (it was actually downloading artifacts from a very slow source).
Another daemon was present so it was not immediately obvious which one was affected (e.g. for jstack or for stopping/killing).

I think it would come handy if the client would print the pid of the daemon that is processing the request.

PS: I could have probably pressed + to see what's going on but nevertheless I do think this would be helpful.

[ppalaga]

+1 for myself. I'd also vote for using shorter daemon IDs. UUIDs are too long to display. E.g. a random Base64 string of length 6 would encode 6 * 6 = 36 bits, which would be more than enough for our use case. WDYT, @gnodet ?

[gnodet]

+1 for myself. I'd also vote for using shorter daemon IDs. UUIDs are too long to display. E.g. a random Base64 string of length 6 would encode 6 * 6 = 36 bits, which would be more than enough for our use case. WDYT, @gnodet ?

Sounds good. Also, while at it, avoiding the use of SecureRandom would be nice, as it ties the client to all the security libs which it would be nice to get rid of in native mode. A crude version is available at https://github.com/fusesource/jansi/blob/master/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L223-L225

    private static String randomUUID() {
        return Long.toHexString(new Random().nextLong());
    }

[famod]

UUIDs are too long to display

Yeah, that's one reason why the process id is better suited, IMHO. Another reason is that, even with a short daemon ID, you don't need to use --status to attach to the process or kill it forcefully.

[famod]

@gnodet Maybe even https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadLocalRandom.html

[gnodet]

+1 for myself. I'd also vote for using shorter daemon IDs. UUIDs are too long to display. E.g. a random Base64 string of length 6 would encode 6 * 6 = 36 bits, which would be more than enough for our use case. WDYT, @gnodet ?

But I'd rather avoid base64 and stick with hex. One of the reason is that it's used in the log file names and I'd rather avoid any possible problem with case sensitivity.

[ppalaga]

OK, hex-encoded int would have 8 characters that sounds acceptable too. We'd have to abs() it so that it can't be negative.

[gnodet]

OK, hex-encoded int would have 8 characters that sounds acceptable too. We'd have to abs() it so that it can't be negative.

I've used the String.format("%08x") which does not add any - sign.

[ppalaga]

OK, hex-encoded int would have 8 characters that sounds acceptable too. We'd have to abs() it so that it can't be negative.

I've used the String.format("%08x") which does not add any - sign.

+1, Math.abs() wouldn't work anyway