[Design of EJB 3.0] - Re: EJB3 Mavenization / Build System Cleanup
by ALRubinger
"wolfc" wrote : I'm thinking of changing the svn directory structure from trunk/... to .../trunk. So we can have independent release cycles for each component. The only con I see is that we don't have the facility in Jira for version per component.
We could still have independent release cycles, but the component releases would be aside one another in branches/.. and tags/..
We *could* configure JIRA to view each "component" (project in SVN) as its own JIRA Project; though that could be overkill and administrative nightmare (instead of EJB3 Project with X Components, we'd have X Projects to watch over).
"wolfc" wrote : The versions of components we depend upon are dictated by the AS component matrix. We can't deviate from that, but we can put a wrapper component in between.
Link to the AS Component Matrix? Or is this simply represented by the componentrefs in build-thirdparty?
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116588#4116588
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116588
16 years, 4 months
[Design of JBossCache] - Problem with after loading Huge data
by sanatmastan
Hi,
I am new to Jboss cache, so i gone through some examples and try to use them to my requirements. here is my requirement. my aim is to store and retrieve frequency of a particular key (String), so i have written a wrapper methods to add, remove, and get frequency for a key. the tricky part here is to take the advantage of tree structure of Jboss cache to implement TRIES data structure, which means the input key will be splitted into chars and inserted in the tree as nodes and the leaf node contains the frequency. If the same key is inserted twice the frequency at the leaf will increase to 2 and so on. This structure helps me to save some space by sharing some of the roots nodes for the different leaf nodes. I didnt implement any replication or persistence mechanism.
The problem here is when i insert 3mil (50mb) entries i am able to get the frequency in the way i am expected and if i try to insert 10mil entries (of size 105mb) all are getting inserted (ofcouse by increasing vm heap size) with out any error, but if i try to verify the existence of a key, i am getting not exist, can anyone comment on this behaviour?
I have few questions.
1) I would like to know whether Jboss cache framework will suite to my requirement where it contain less depth (20 to 30 levels) and huge breath size (in thousands)?
2) Is there any limitations on Jboss cache memory size?
Please clarify...
Thanks in advance
Sanat.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116585#4116585
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116585
16 years, 4 months
[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re
by manik.surtani@jboss.com
"jason.greene(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : Twist on this I just remembered. With entity caching, user types can be part of the FQN as well. Primary key of the entity is the last element of the FQN. A user type in an FQN is of course generally possible; entity caching is just a particular example where I've had to handle it with region-based marshalling. (The region portion of the FQN is only strings).
|
| IMO we should start requiring that FQNs are only composed of serializable types that are on the cache classpath. POJO Cache does a very similar thing to entity caching, and it should also be changed not to do this. We should instead compute a value based off of the hash code. In my case, which should be possible with an entity cache, I can actually allow collisions, by simply using the key object as an attribute (key) on the node, instead of the last element of an fqn. The value of the key would point to an internal fqn, containing the data of the object. Alternatively, a sub fqn structure could be created using a unique value. In this alternative case, you would have to iterate all children, performing a comparison.
|
| -Jason
|
|
+100. Hugely limiting in the way we have to support custom objects in Fqns right now. I understand why people don't want just Strings as Fqn elements, but we should restrict this to Strings + boxed primitives or something like that.
Again, though, not something we can do now (2.1.0). Perhaps 3.0.0?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116529#4116529
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116529
16 years, 4 months
[Design of JBossCache] - Re: Implicit marshalled values - a better way of handling re
by jason.greene@jboss.com
"bstansberry(a)jboss.com" wrote : Twist on this I just remembered. With entity caching, user types can be part of the FQN as well. Primary key of the entity is the last element of the FQN. A user type in an FQN is of course generally possible; entity caching is just a particular example where I've had to handle it with region-based marshalling. (The region portion of the FQN is only strings).
IMO we should start requiring that FQNs are only composed of serializable types that are on the cache classpath. POJO Cache does a very similar thing to entity caching, and it should also be changed not to do this. We should instead compute a value based off of the hash code. In my case, which should be possible with an entity cache, I can actually allow collisions, by simply using the key object as an attribute (key) on the node, instead of the last element of an fqn. The value of the key would point to an internal fqn, containing the data of the object. Alternatively, a sub fqn structure could be created using a unique value. In this alternative case, you would have to iterate all children, performing a comparison.
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116521#4116521
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116521
16 years, 4 months
[Design of AOP on JBoss (Aspects/JBoss)] - Deadlock scenarios
by flavia.rainone@jboss.com
During rebuildingchain test execution, we are seeing a couple of deadlock scenarios... those are related to classload time weaving and dynamic AOP operations.
I have created a bug issue:
http://jira.jboss.com/jira/browse/JBAOP-499
With two subtasks:
http://jira.jboss.com/jira/browse/JBAOP-500
http://jira.jboss.com/jira/browse/JBAOP-501
The first scenario (JBAOP-500) started happening after bug fix JBAOP-480.
It can be stopped if JBoss AOP starts avoiding to transform the generated joinpoint classes (on class AOPTransformer). For that, simply adding an aop suffix to the generated class name would work.
However, in the second scenario, JBAOP-501, the deadlock can happen when one of the threads executes an AspectManager synchronized operation that needs to load an advisable class, while the other thread starts loading an advisable class. So, the first thread has AspectManager lock but needs the class loader lock, while the second thread has the class loader lock but needs the AspectManager one to try to transform the advisable class.
I have a suggestion to fix this, but I'm not sure it can be applied on the possible scenarios (this info is something we would need to gather).
My idea will work only if we can state that all the advisable instances that JBoss AOP creates during AspectManager synchronized method executions won't be instrumented. If this is true, we can start considering those instances as non-advisable instead of advisable. In this case, we would need to check if the class is advisable at method AspectManager.transform (which is non-synchronized), before calling translate (which is synchronized). This would halt the transformation process on the given deadlock scenarios before acquiring AspectManager lock, avoiding the deadlock.
Using the thread dump scenario provided by Stale as an example (described on task JBAOP-501), the deadlock happens when JBoss AOP loads an Interceptor class to create. In this case can we say that Interceptors shouldn't be instrumented? If we can, we can go for the approach above for this scenario.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116505#4116505
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116505
16 years, 4 months