• BWill (unregistered)

    There is a "not" missing in "webserver shutting down properly".

  • TheCPUWizard (unregistered)

    Disagree : there is a probability that the designers of the code [a third party] did not consider the use case required. Of course the is the possibility to not use that package and find a different offering or roll your own (perhaps 10's of thousands of lines). If the code does indeed deadlock, and there is not a valid (documented, supported b the vendor) means of addressing the issue, this is perfectly valid EXCEPT the "voodoo comment" - instead there should be proper explanation of why this was necessary

  • TheCPUWizard (unregistered)

    "my name (unregistered)" -- How would a kill 9 on a PROCESS, allow the PROCESS to properly run while shutting down ONE SPECIFIC thread...???

  • (nodebb)

    I am not sure in which version Java closed this nasty holes in the language, but this no longer works in Java 17. In Java 8, it prints "One=2".

        Integer one = 1;
    Class<Integer> c = Integer.class;
    Field f = c.getDeclaredField("value");
    f.setAccessible(true);
    f.set(one, 2);

    Integer[] ints = {1};
    System.out.println("One=" + ints[0]);

    Addendum 2024-07-25 11:27: The real WTF was setAccessible.

  • Hanzito (unregistered)

    Exatly! That's why we don't upgrade Java anymore. Too dangerous.

    -- Jaco's CTO, probably.

  • Lothar (unregistered)

    The comment above the "voodoo"-one explains the necessity: The regular way shutting down the WebServer leads to a deadlock. This looks like some third-party library where you need to wait for a fix from the provider, but until then you need to find a way to shut down the (supposedly) non-daemon-threads of that web server that prevent your own application to shut down properly: A java process doesn't exit unless all non-daemon-threads are terminated.

    BTDT myself and you can be sure that the one who did it, felt bad while doing it. But there are occasions where this simply is necessary. Another example was doing SSL Session resumption on an FTP data-connection with the standard TLS library that comes with the JVM. Simply put: You can't but if you need to, you need your Reflection-Voodoo ready: https://eng.wealthfront.com/2016/06/10/c/

  • (nodebb)

    Since that listener is a thread, we can simply interrupt() it to break its execution. That is the correct way to stop a thread in Java, which is the first correct thing this code has done.

    Maybe. Maybe not. According to the Java docs the thread needs to support interruption. i.e. it needs to call a method that can throw InterruptedException or periodically inspect its interrupted() property. More insidiously, the writer might have decided to catch InterruptedException, swallow it and then carry on.

  • Ex-Java dev (unregistered)

    Only problem is that interrupts in java are handled by throwing an exception. An exception that can be caught, especially in calls to external services, say, a database with a third party library like, say, Spring/JDBC. Ask me how I know.

    Also, I love reflection. Didn't get to use it much, and mostly used it for configuration/set-up stuff outside of weird investigative one-offs, but always a blast.

  • Ex-Java dev (unregistered)

    Only problem is that interrupts in java are handled by throwing an exception. An exception that can be caught, especially in calls to external services, say, a database with a third party library like, say, Spring/JDBC. Ask me how I know.

    Also, I love reflection. Didn't get to use it much, and mostly used it for configuration/set-up stuff outside of weird investigative one-offs, but always a blast.

  • LXE (unregistered)

    The "helpful tip" implies that all code beyond our control is written the way it should. In other words, we are in paradise, and I want my nectar and ambrosia.

  • my name (unregistered) in reply to TheCPUWizard

    he wants to shutdown the webserver, so I buttumed the webserver would run in its own process

  • smf (unregistered)

    If you haven't had to use reflection to get access to some private method or variable, then you haven't done any real programming.

  • What WTF? (unregistered)

    If it's your own code, sure, this is a WTF. But it sounds like this is a 3rd-party component that doesn't follow "best-coding practice". In that situation, sure, I'd do this too.

    The real WTF here is somehow assuming that this wasn't necessary when the comment itself shows that trying to do it the "sane" way results in a deadlock. And from the deliberate way it's been done, it looks like someone decompiled the code, carefully checked what could be done to make the component shutdown sanely, and did that.

    I don't even agree with commenters on this thread saying "explain why this works"… let's see, you set the "listener" field to null on a network service. It's quite self explanatory. If you don't know why that might work to gum up the works, maybe you've never done anything with networks… and in that case, what's the point of explaining with a paragraph of comments?

  • (nodebb)

    Depends on a lot of things, 'kill -9' isn't the first thing you should reach for.

    The database we use at work runs in 'Shared Memory', this makes it extremely quick, since it doesn't have to rely on sockets, etc... The system built on top of it runs in shared memory mode to talk to the database.

    If the code gets stuck, going straight to 'kill -9' means the database goes down too.

    One should always go up the kill stack, start off kind and get more aggressive as you go along.

Leave a comment on “Reflections on Privacy”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article