2362N/A * Copyright (c) 2004, 2007, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 2362N/A * or visit www.oracle.com if you need additional information or have any 0N/A * @summary Tests that thread creation can use a user-supplied Executor 0N/A * @author Eamonn McManus 0N/A * @run clean ExecutorTest 0N/A * @run build ExecutorTest 0N/A * @run main ExecutorTest 0N/A When you create a JMXConnector client, you can supply a 0N/A "fetch-notifications Executor", which is a 0N/A java.util.concurrent.Executor that will be used each time the 0N/A connector client wants to call RMIConnection.fetchNotifications. 0N/A This is a hook that allows users to make that potentially-blocking 0N/A call from within a thread pool or the like. If you have very many 0N/A connections, you can potentially share the work of 0N/A fetchNotifications calls among a number of threads that is less than 0N/A the number of connections, decreasing thread usage at the expense of 0N/A This test checks that the environment property does in fact work. 0N/A It creates a connection without that property and ensures that 0N/A notification sending does in fact work (with the default Executor). 0N/A Then it creates a connection with the property set to an Executor 0N/A that records how many times its execute method is invoked. 0N/A Notifications are sent one by one and each time the test waits for 0N/A the notification to be received. This implies that 0N/A fetchNotifications will be executed at least as many times as there 0N/A are notifications. Since each fetchNotifications call is supposed 0N/A to happen as an Executor.execute call, if Executor.execute has been 0N/A called fewer times then there were notifications, we know that the 0N/A Executor is not being used correctly. 0N/A "jmx.remote.x.fetch.notifications.executor";
0N/A // Create server just to see if the protocol is supported 0N/A return "Incorrect method count for execute: " +
count;
0N/A /* Simple MBean that sends a notification every time we ask it to. */ 0N/A /* Simple NotificationListener that allows you to wait until a 0N/A notification has been received. Since it uses a semaphore, you 0N/A can wait either before or after the notification has in fact 0N/A been received and it will work in either case. */ 0N/A /* Ensure no extra notifications were received. If we can acquire 0N/A the semaphore, that means its release() method was called more 0N/A times than its acquire() method, which means there were too 0N/A many notifications. */ 0N/A /* Generic InvocationHandler that forwards all methods to a wrapped 0N/A object, but counts for each method how many times it was invoked. */