[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by bstansberry＠jboss.com
"andy.miller(a)jboss.com" wrote :
| I do have the above in my ejb3-interceptors-aop.xml.
|
| Here is the behavior I see:
|
| With just @Clustered and no Cache or CacheConfig annotation, I get the StatefulTreeCache.
Good.
anonymous wrote : I think you say that using jboss.cache:service=EJB3SFSBClusteredCache doesn't work, and you would be correct. I had that, and I get no deployment error, but I still get StatefulTreeCache.
No, that's not what I meant; what you see is what I expect.
There's a couple of concepts here; one of which users normally don't need to worry about, the other they do.
The first is what implementation of the "StatefulCache" interface EJB3 will use. This is the one users normally don't have to worry about. That interface defines the SPI the EJB3 container uses to interact with the caching subsystem. "StatefulTreeCache" is an implementation of that SPI that knows how to interact with JBC. "SimpleStatefulCache" is an implementation that works with the filesystem.
You only became aware of this stuff because you had the @Clustered package issue that caused EJB3 to use the wrong one. With that fixed, with @Clustered you should always see "StatefulTreeCache".
The second concept is how to configure whatever impl of StatefulCache is used. That's an end user concern and is done via the @CacheConfig annotation. The ejb3-interceptors-aop.xml stuff you saw is just a way of setting defaults if you don't add the annotation yourself.
StatefulTreeCache uses the @CacheConfig.name attribute to tell it what JBoss Cache configuration to use. It gets the JBC instance from the CacheManager service by passing in the @CacheConfig.name value. The standard value it should pass in is "sfsb-cache", but if it passes in the legacy AS 4.x default value of "jboss.cache:service=EJB3SFSBClusteredCache", the CacheManager knows that's just an alias for the AS 5.x default of "sfsb-cache".
So, this part sounds like its working just fine.
anonymous wrote : With @Clustered and @CacheConfig(name="sfsb-cache", maxSize=125000) I still get StatefulTreeCache (not the EJB3SFSBStatefulTreeCache), and the size shows -1 in the jmx-console, and when I run it I still only get 10,000 as the max size. I just figured 10,000 because it never goes above that when refreshing, and when it gets close to that size is when passivation occurs.
Yes, why the config value of maxSize=100,000 doesn't seem to be respected is what I need to figure out.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184015#4184015
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184015
17 years, 5 months
[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by andy.miller＠jboss.com
"bstansberry(a)jboss.com" wrote : You would add an @CacheConfig annotation:
|
| @org.jboss.ejb3.annotation.CacheConfig (name="sfsb-cache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
|
| The maxSize param controls the max number of beans.
|
| If you don't configure that, and your bean is @Clustered, per the deploy/ejb3-interceptors-aop.xml I have in my workspace, the following should be added to your bean:
|
| @org.jboss.ejb3.annotation.CacheConfig (name="jboss.cache:service=EJB3SFSBClusteredCache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
|
| It already has a maxSize of 100,000 so I'm not sure how you're ending up with only 10,000. I'll poke around.
|
| The name="jboss.cache:service=EJB3SFSBClusteredCache" bit needs to be fixed: https://jira.jboss.org/jira/browse/JBAS-6128 . The way StatefulTreeCache uses that value in AS 5 is to drive a lookup in the CacheManager service, deployed via deploy/cluster/jboss-cache-manager.sar. CacheManager is an on-demand factory for JBoss Cache instances. It's maintains a registry of named JBC configurations, and provides caches based on the name.
|
| The name here should be "sfsb-cache". The cache manager is configured to understand the old 4.x name "jboss.cache:service=EJB3SFSBClusteredCache" to be an alias for "sfsb-cache". That allows pre-existing code to work.
|
| If you actually wanted to play around with the "sfsb-cache" JBC configuration, you could edit deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-configs.xml. But I don't think that's what you are looking for; you don't control things like the max # of beans via JBC configuration; it's via @CacheConfig.
|
| Obviously this needs documenting. :(
|
| Does the deploy/ejb3-interceptors-aop.xml file on your JBoss install include this?
|
| <annotation expr="!class((a)org.jboss.ejb3.annotation.CacheConfig) AND class((a)org.jboss.ejb3.annotation.Clustered)">
| | @org.jboss.ejb3.annotation.CacheConfig (name="jboss.cache:service=EJB3SFSBClusteredCache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
| | </annotation>
| |
|
| If your maxSize value were something different, that would explain it.
I do have the above in my ejb3-interceptors-aop.xml.
Here is the behavior I see:
With just @Clustered and no Cache or CacheConfig annotation, I get the StatefulTreeCache.
I think you say that using jboss.cache:service=EJB3SFSBClusteredCache doesn't work, and you would be correct. I had that, and I get no deployment error, but I still get StatefulTreeCache.
With @Clustered and @CacheConfig(name="sfsb-cache", maxSize=125000) I still get StatefulTreeCache (not the EJB3SFSBStatefulTreeCache), and the size shows -1 in the jmx-console, and when I run it I still only get 10,000 as the max size. I just figured 10,000 because it never goes above that when refreshing, and when it gets close to that size is when passivation occurs.
This just doesn't appear to be working correctly at all.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184013#4184013
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184013
17 years, 5 months
[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by bstansberry＠jboss.com
You would add an @CacheConfig annotation:
@org.jboss.ejb3.annotation.CacheConfig (name="sfsb-cache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
The maxSize param controls the max number of beans.
If you don't configure that, and your bean is @Clustered, per the deploy/ejb3-interceptors-aop.xml I have in my workspace, the following should be added to your bean:
@org.jboss.ejb3.annotation.CacheConfig (name="jboss.cache:service=EJB3SFSBClusteredCache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
It already has a maxSize of 100,000 so I'm not sure how you're ending up with only 10,000. I'll poke around.
The name="jboss.cache:service=EJB3SFSBClusteredCache" bit needs to be fixed: https://jira.jboss.org/jira/browse/JBAS-6128 . The way StatefulTreeCache uses that value in AS 5 is to drive a lookup in the CacheManager service, deployed via deploy/cluster/jboss-cache-manager.sar. CacheManager is an on-demand factory for JBoss Cache instances. It's maintains a registry of named JBC configurations, and provides caches based on the name.
The name here should be "sfsb-cache". The cache manager is configured to understand the old 4.x name "jboss.cache:service=EJB3SFSBClusteredCache" to be an alias for "sfsb-cache". That allows pre-existing code to work.
If you actually wanted to play around with the "sfsb-cache" JBC configuration, you could edit deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-configs.xml. But I don't think that's what you are looking for; you don't control things like the max # of beans via JBC configuration; it's via @CacheConfig.
Obviously this needs documenting. :(
Does the deploy/ejb3-interceptors-aop.xml file on your JBoss install include this?
<annotation expr="!class((a)org.jboss.ejb3.annotation.CacheConfig) AND class((a)org.jboss.ejb3.annotation.Clustered)">
| @org.jboss.ejb3.annotation.CacheConfig (name="jboss.cache:service=EJB3SFSBClusteredCache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
| </annotation>
|
If your maxSize value were something different, that would explain it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184011#4184011
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184011
17 years, 5 months
[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by kukeltje
"heiko.braun(a)jboss.com" wrote : anonymous wrote :
| | So to me a full blown graphical console doesnt add much to end-users. It is more important to make the jbpm data available through an easy to use api
| |
|
| I don't agree with this. IMO the API is not necessary because it has a DB schema already, which is ready for consumption. Actually I think quiet the opposite of what you say. Adding an API atop of the schema would just narrow the possibilities to query according to users demands.
|
| However, it is right that customization plays a huge part here. But to begin with I think we should be able to define a set of common analytical and operational questions user typical ask and build that into a console.
|
What is important is that (from my experience) users want to drill down to individual case data when using the dashboard for both operational data and analytical data (if it is still available). Since we advise people not to put all data in jBPM (as opposed to other BPM suppliers to a certain extend), but use their own domain model and storage, there should be e.g. a basic api that returns all businesskeys related to that period or an individual case (a business key being the FK between the domain and the processinstance). That way users can analyse bottlenecks more easily. Since I cannot imagine the jBPM console showing the domain data, an api with basic methods does sound interesting. Users can embed the basic operational/analytical data in their own apps then. Basic being the keyword!!
For more complex analytical dashboards, I personally advice my customer (hope there will be more) to use a real BI/BAM (sorry) product like Pentaho or Jaspersoft, since they often need this for other analysis as well, but that is just me. And since I saw you are using jaspersoft, maybe things will turn around.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184009#4184009
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184009
17 years, 5 months
[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by andy.miller＠jboss.com
"bstansberry(a)jboss.com" wrote : I see it. You are using :
|
| import org.jboss.annotation.ejb.Clustered;
|
| which was removed a long time ago as part of the reorganization of EJB3 annotations; now it is:
|
| import org.jboss.ejb3.annotation.Clustered;
Okay, I rebuilt the application with the AS 5 libraries, and I am no longer getting the SimpleStatefulCache, but instead am getting the StatefulTreeCache.
You cannot configure the StatefulTreeCache (at least I can't see how), so my throughput has now dropped, even though I don't have the hang situation anymore. The StatefulTreeCache doesn't appear to have a maxSize, and it seems to be limited to 10,000 beans.
So, the question I have, is how do I get it to pick up the EJB3SFSBSClusteredCache. It appears I would need to add an annotation (@Cache or @CacheConfig), but the documentation for both of these is out-of-date, and the source has no explanation (no javadoc).
Any ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184003#4184003
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184003
17 years, 5 months
[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World
by andy.miller＠jboss.com
"wolfc" wrote : That takes care of the cache configuration, but I also want to know what's behind this passivation issue.
|
| Is passivating or activating the culprit?
| On what OS is this?
|
| If it was the sync on cacheMap I would say a deadlock would happen, not some timeout of 30 seconds.
The issue is clearly passivation. The passivation count is zero on the first occurrence, and everything hangs, and then the passivation count is non-zero. The only time the hang occurs is when passivation happens. My typical response times on calling the stateful session bean and returning with the result set are between 7 and 40ms.
This is being run on Fedora 9, with our OpenJDK 6 JVM.
After rebuilding with the AS 5 CR 2 libraries, the problem does go away, because I now have confirmed that I'm using the StatefulTreeCache, which is the default in the ejb3-interceptors-aop.xml based on the fact that I only have the @Clustered annotation:
| <!-- Clustered cache configuration -->
| <annotation expr="!class((a)org.jboss.ejb3.annotation.Cache) AND class((a)org.jboss.ejb3.annotation.Clustered)">
| @org.jboss.ejb3.annotation.Cache ("StatefulTreeCache")
| </annotation>
| <annotation expr="!class((a)org.jboss.ejb3.annotation.CacheConfig) AND class((a)org.jboss.ejb3.annotation.Clustered)">
| @org.jboss.ejb3.annotation.CacheConfig (name="jboss.cache:service=EJB3SFSBClusteredCache", maxSize=100000, idleTimeoutSeconds=300, removalTimeoutSeconds=0)
| </annotation>
|
Clearly the synchronization in the SimpleStatefulCache is a real problem. If I weren't running in a clustered configuration (and didn't have the issue I had because I didn't rebuild with the AS 5 libraries), I would still have the same problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184001#4184001
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184001
17 years, 5 months