3 Replies Latest reply on May 11, 2010 10:41 AM by cullendw

    Configuration bug in infinispan

    cullendw

      Hi,

       

      We are attempting to upgrade from jboss cache to infinispan 4.0. We have encountered a bug which is caused by the terrible API from java.util.Properties.

       

      A simple test case shows what the subtlety is :

       

                Properties p = new Properties();
                p.put("hi", "there");

                System.out.println(p.get("hi"));
                System.out.println(p.containsKey("hi"));

                /*
                * attempt a defensive copy of p - however, this only sets the defaults in the new
                * properties object, so direct calls to the parent map do
                * not work as expected
                */

                Properties p2 = new Properties(p);
                System.out.println(p2.get("hi"));
                System.out.println(p2.containsKey("hi"));

       

      This produces the following output

       

       

       

      there

      true


      null

      false

       

       

      Now, Infinispan does the following org.infinispan.factories.NamedExecutorsFactory :

       

       

       

         private ExecutorService buildAndConfigureExecutorService(String factoryName, Properties p, String componentName) throws Exception {

            Properties props = new Properties(p); // defensive copy

            ExecutorFactory f = (ExecutorFactory) Util.getInstance(factoryName);

            setComponentName(componentName, props);

            setDefaultThreads(KnownComponentNames.getDefaultThreads(componentName), props);

            setDefaultThreadPrio(KnownComponentNames.getDefaultThreadPrio(componentName), props);

            return f.getExecutor(props);

         }

       

       

      ...


       

         private void setDefaultThreadPrio(int prio, Properties props) {

            if (!props.containsKey("threadPriority")) props.setProperty("threadPriority", String.valueOf(prio));

         }


         private void setDefaultThreads(int numThreads, Properties props) {

            if (!props.containsKey("maxThreads")) props.setProperty("maxThreads", String.valueOf(numThreads));

         }

       

       

      The buildAndConfigureExecutorService method attempts a defensive copy of the properties (but just sets the defaults for props instead), and the helper methods (example : setDefaultThreads) uses the containsKey method from java.util.Properties which will return false based on the previous example.

       

      This means that the properties specified for the Async Listeners will not be set, but rather defaulted because of this subtlety.

       

      Before logging a Jira, does anyone know if this has been fixed and there is a patch