First draft of Cache interface available

[belaban]

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)

[belaban]

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

[lorensrosen]

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.

[belaban]

> 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

[lorensrosen]

>
> 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.

[belaban]

> 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