Java Code Examples for com.sun.jmx.examples.scandir.ScanManagerMXBean.ScanState#CLOSED

The following examples show how to use com.sun.jmx.examples.scandir.ScanManagerMXBean.ScanState#CLOSED . You can vote up the ones you like or vote down the ones you don't like, and go to the original project or source file by following the links above each example. You may check out the related API usage on the sidebar.
Example 1
Source File: ScanDirAgent.java    From dragonwell8_jdk with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 2
Source File: ScanDirAgent.java    From TencentKona-8 with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 3
Source File: ScanDirAgent.java    From jdk8u60 with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 4
Source File: ScanDirAgent.java    From openjdk-jdk8u with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 5
Source File: ScanDirAgent.java    From openjdk-jdk8u-backup with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 6
Source File: ScanDirAgent.java    From jdk8u-jdk with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 7
Source File: ScanDirAgent.java    From hottub with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 8
Source File: ScanDirAgent.java    From openjdk-8-source with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 9
Source File: ScanDirAgent.java    From openjdk-8 with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 10
Source File: ScanDirAgent.java    From jdk8u_jdk with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 11
Source File: ScanDirAgent.java    From jdk8u-jdk with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}
Example 12
Source File: ScanDirAgent.java    From jdk8u-dev-jdk with GNU General Public License v2.0 4 votes vote down vote up 
/**
 * Wait for someone to call 'close()' on the ScanManagerMXBean singleton.
 * Every time its state changes, the ScanManagerMXBean emits a notification.
 * We don't rely on the notification content (if we were using a remote
 * connection, we could miss some notifications) - we simply use the
 * state change notifications to react more quickly to state changes.
 * We do so simply by polling the {@link BlockingQueue} in which our
 * listener is pushing notifications, and checking the ScanManagerMXBean
 * state every time that a notification is received.
 * <p>
 * We can do so because we know that once the ScanManagerMXBean state is
 * switched to 'CLOSED', it will remain 'CLOSED' whatsoever. <br>
 * Therefore we don't need to concern ourselves with the possibility of
 * missing the window in which the ScanManagerMXBean state's will be
 * CLOSED, because that particular window stays opened forever.
 * <p>
 * Had we wanted to wait for 'RUNNING', we would have needed to apply
 * a different strategy - e.g. by taking into account the actual content
 * of the state changed notifications we received.
 * @throws java.io.IOException wait failed - a communication problem occurred.
 * @throws javax.management.JMException wait failed - the MBeanServer threw an exception.
 */
public void waitForClose() throws IOException, JMException {

    // Wait until state is closed
    while(proxy.getState() != ScanState.CLOSED ) {
        try {
            // Wake up at least every 30 seconds - if we missed a
            // notification - we will at least get a chance to
            // call getState(). 30 seconds is obviously quite
            // arbitrary - if this were a real daemon - id'be tempted
            // to wait 30 minutes - knowing that any incoming
            // notification will wake me up anyway.
            // Note: we simply use the state change notifications to
            // react more quickly to state changes: see javadoc above.
            //
            queue.poll(30,TimeUnit.SECONDS);
        } catch (InterruptedException ex) {
            // OK
        }
    }
}