5 Replies Latest reply on Jan 15, 2003 12:19 AM by Bela Ban

    First draft of Cache interface available

    Bela Ban Master

      CAN NOT undeploy & redeploy jar & war files in jbosside 1.4.0 / eclipse 3.0.1, why?

      and JSP Editor (Jboss-IDE) always not working!!!
      error occurred like this:

      SOMEBODY HELP ME????????

      java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/jdt/j2ee/jsp/core/compiler/jasper/JSPServletContext$IJSPContentProvider
      at org.jboss.ide.eclipse.jdt.j2ee.jsp.ui.editors.JSPEditor.initializeEditor(JSPEditor.java:140)
      at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.(AbstractDecoratedTextEditor.java:177)
      at org.eclipse.ui.editors.text.TextEditor.(TextEditor.java:70)
      at org.jboss.ide.eclipse.jdt.ui.editors.I18NTextEditor.(I18NTextEditor.java:27)
      at org.jboss.ide.eclipse.jdt.j2ee.jsp.ui.editors.JSPEditor.(JSPEditor.java:34)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
      at java.lang.Class.newInstance0(Class.java:308)
      at java.lang.Class.newInstance(Class.java:261)
      at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:141)
      at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:124)
      at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:113)
      at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:189)
      at org.eclipse.ui.internal.EditorManager$5.run(EditorManager.java:787)
      at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:616)
      at org.eclipse.core.runtime.Platform.run(Platform.java:747)
      at org.eclipse.ui.internal.EditorManager.createPart(EditorManager.java:785)
      at org.eclipse.ui.internal.EditorManager.openInternalEditor(EditorManager.java:772)
      at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:582)
      at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:570)
      at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2244)
      at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2177)
      at org.eclipse.ui.internal.WorkbenchPage.access$6(WorkbenchPage.java:2169)
      at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.java:2156)
      at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
      at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2151)
      at org.eclipse.ui.ide.IDE.openEditor(IDE.java:299)
      at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:137)
      at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:110)
      at org.eclipse.jdt.internal.ui.actions.OpenActionUtil.open(OpenActionUtil.java:49)
      at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:164)
      at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:150)
      at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:212)
      at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:188)
      at org.eclipse.jdt.internal.ui.packageview.PackageExplorerActionGroup.handleOpen(PackageExplorerActionGroup.java:289)
      at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$4.open(PackageExplorerPart.java:490)
      at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:429)
      at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:616)
      at org.eclipse.core.runtime.Platform.run(Platform.java:747)
      at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:427)
      at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:635)
      at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:731)
      at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:211)
      at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:206)
      at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:238)
      at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82)
      at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796)
      at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2772)
      at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2431)
      at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1377)
      at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348)
      at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:254)
      at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141)
      at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96)
      at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335)
      at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
      at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
      at org.eclipse.core.launcher.Main.run(Main.java:704)
      at org.eclipse.core.launcher.Main.main(Main.java:688)

        • 1. Re: First draft of Cache interface available
          Bela Ban Master

          I forgot to mention: you can generate the javadoc for Cache from jboss head by
          - cd jboss-head/cache
          - build.sh docs

          This will create jboss-head/cache/output/api

          Bela

          • 2. Re: First draft of Cache interface available
            Loren Rosen Newbie

            I've got a few questions and comments after an initial
            read-through:

            What about updates to items in the cache? From the use cases document it sounds like there are scenarios where you wish to propagate these.

            Must all the caches in a cluster be configured the same (same size, same eviction policy, etc.)? If so, what support is provided to help insure this is so?

            Can the cache configuration be changed at run-time (e.g. resize the cache)? Are these changed propagated across the cluster?

            Have you thought about what eviction policies to support?

            Now some more specific comments on parts of the Cache interface:

            addListener, removeListener: are these the interceptors or something else?

            method overloading: the method overloads have parameters of the same types but different meanings (e.g. booleans sometimes indicate that the operation is synchronous and sometimes mean that a commit should occur). I think this is a recipe for confusion. (I'd be happier if Java supported named parameter association but without it I'm leery of overloads with lengthy parameter lists.)

            The triple (sync_timeout, lock_acquisition_timeout, lock_lease_timeout) occurs in a number of parameter lists. This suggests there is an independent concept
            hiding here which should be factored out.

            • 3. Re: First draft of Cache interface available
              Bela Ban Master


              > What about updates to items in the cache? From the
              > use cases document it sounds like there are scenarios
              > where you wish to propagate these.

              Yes: if an item is to be replicated, all changes will be propagated to all caches in the cluster.


              > Must all the caches in a cluster be configured the
              > same (same size, same eviction policy, etc.)? If so,
              > what support is provided to help insure this is so?

              I guess same config is the easiest option in a first shot. But I don't see why different caches in the same cluster cannot have different cache sizes, eviction policies etc.

              Note that my current thinking is that, if a cache entry is evicted in a replicated cache, then that entry will be removed from all caches in the cluster.


              > Can the cache configuration be changed at run-time
              > (e.g. resize the cache)? Are these changed propagated
              > across the cluster?


              That should be possible. I added it to the TODO list. If the new cache size is smaller than the actual items, do we want to evict the diff, or do we wait until attrition has reduced the cache size ? I'm for immediate eviction.


              > Have you thought about what eviction policies to support?


              No. So far I have only focused on providing hooks so that different eviction policies can be plugged in. This needs some more work: I'll need to make sure that eviction policies have access to the internals of a Cache.



              > addListener, removeListener: are these the
              > interceptors or something else?

              No. The interceptor-based design I described in the docs would go much further. CacheListeners are for now mainly used by eviction policies.



              > The triple (sync_timeout, lock_acquisition_timeout,
              > lock_lease_timeout) occurs in a number of parameter
              > lists. This suggests there is an independent concept
              > hiding here which should be factored out.

              The aspect is 'replication'. However, it being a core aspect of the JBoss Cache, I don't want to implement it as an aspect for now. Also, if you want to vary cache replication parameters per method call I don't see another way of doing it.

              Suggestions ?

              Bela

              • 4. Re: First draft of Cache interface available
                Loren Rosen Newbie

                >
                > Yes: if an item is to be replicated, all changes will
                > be propagated to all caches in the cluster.

                Okay, so there's a task (for the task list) to implement
                this. What sort of locking or update conflict resolution
                policies do you envision? Also, is the notion that an
                element added to one cache is added to all the others
                as well?

                >
                >
                > > Must all the caches in a cluster be configured the
                > > same (same size, same eviction policy, etc.)? If
                > so,
                > > what support is provided to help insure this is
                > so?
                >
                > I guess same config is the easiest option in a first
                > shot. But I don't see why different caches in the
                > same cluster cannot have different cache sizes,
                > eviction policies etc.
                >
                > Note that my current thinking is that, if a cache
                > entry is evicted in a replicated cache, then that
                > entry will be removed from all caches in the
                > cluster.

                If eviction is global, then there's little point to
                having varying cache sizes.

                >
                >
                > > Can the cache configuration be changed at run-time
                > > (e.g. resize the cache)? Are these changed
                > propagated
                > > across the cluster?
                >
                >
                > That should be possible. I added it to the TODO list.
                > If the new cache size is smaller than the actual
                > items, do we want to evict the diff, or do we wait
                > until attrition has reduced the cache size ? I'm for
                > immediate eviction.

                This needs to be added to the sourceforge task list--
                I assume that's the one you're using for tracking.

                Immediate eviction seems fine to me.

                >
                >
                > > Have you thought about what eviction policies to
                > support?
                >
                >
                > No. So far I have only focused on providing hooks so
                > that different eviction policies can be plugged in.
                > This needs some more work: I'll need to make sure
                > that eviction policies have access to the internals
                > of a Cache.
                >

                In addition, there are some management things that will
                need access to the internals. For example, you should be
                able to track and query the cache hit ratio. Another
                task for the list.

                A related question is whether side data that is part
                of the eviction policy, e.g. LRU data, is propagated
                between caches.

                >
                >
                > > addListener, removeListener: are these the
                > > interceptors or something else?
                >
                > No. The interceptor-based design I described in the
                > docs would go much further. CacheListeners are for
                > now mainly used by eviction policies.

                Okay, though I assume longer-term the evictors can
                be changed into interceptors as well.

                >
                >
                >
                > > The triple (sync_timeout,
                > lock_acquisition_timeout,
                > > lock_lease_timeout) occurs in a number of
                > parameter
                > > lists. This suggests there is an independent
                > concept
                > > hiding here which should be factored out.
                >
                > The aspect is 'replication'. However, it being a core
                > aspect of the JBoss Cache, I don't want to implement
                > it as an aspect for now. Also, if you want to vary
                > cache replication parameters per method call I don't
                > see another way of doing it.
                >
                > Suggestions ?

                I'll comment on this elsewhere after I've looked at
                the changes you've made.

                • 5. Re: First draft of Cache interface available
                  Bela Ban Master

                  > What sort of locking or update conflict resolution
                  > policies do you envision?

                  I'll get to that soon. My idea is to provide something similar to DB transactions (dirty reads, read-committed and maybe repeatable reads and total serializability). Or maybe also a variation thereof, more suitable for distributed locking.
                  If you check out Xid.java, I have already provided for several types of transactions. Nothing's final though.


                  > Also, is the notion that an
                  > element added to one cache is added to all the
                  > others as well?

                  Yes, if the cache is configured to replicate its entries.




                  > If eviction is global, then there's little point to
                  > having varying cache sizes.

                  Not necessarily. We might have caches which have a mix of transient and replicated entries. Of course, if eviction is global, then the number of replicated entries would be the same across all caches, but the number of transient items will vary from cache to cache.






                  > A related question is whether side data that is part
                  > of the eviction policy, e.g. LRU data, is propagated
                  > between caches.

                  Haven't given this much thought. Side data might be managed by each cache independently, only updates to the caches would be replicated (if non-transient).



                  > Okay, though I assume longer-term the evictors can
                  > be changed into interceptors as well.

                  Yes, that should be possible.



                  > I'll comment on this elsewhere after I've looked at
                  > the changes you've made.

                  Note that I have reduced the number of overloaded methods from 4 to 2. For example, there's the (almost) default put(Object,Object), and then there's one which accepts an Option object, in which you can override default values on a per-method basis.

                  Bela