[jBPM] New message: "Re: Upgrade from JBPM3 to JBPM4 woes"
by nick bauman
User development,
A new message was posted in the thread "Upgrade from JBPM3 to JBPM4 woes":
http://community.jboss.org/message/524202#524202
Author : nick bauman
Profile : http://community.jboss.org/people/nick.bauman
Message:
--------------------------------------------------------------
Ronald,
Great tips, really appreciate!
> You can often cast to *Impl classes and do more
I think I was poking around and saw that, but it didn't feel good to downcast. I'll have another look.
We have been able to get pretty far with executionService too like you describe, too. The Node versus State discussion is my bad: I always saw State as being non-transient and Node as being transient: having written an FSM in both Java and JavaScript, I guess I have my own prejudices and they're showing. I used the concept of Guards on Transitions that held the decision logic instead of using Decision states. Nothing wrong with Decision States, mind you.
> Nobody ever did fix the template.... why? Not used a lot? Scared? .... If I may ask why didn't you?
I think I just weren't at a place where I felt we had it down and felt justified enough to change what's in the jar and submit a patch. There is quite a bit of resistance initially (technical debt incurrance being only one consideration) to going into 3rd party code unless you're really sure you know what you're talking about: to whit this conversation
Thanks again,
Nick
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524202#524202
16 years, 2 months
[JBoss Cache] New message: "Re: How to manage empty data with a CacheLoader?"
by Nicolas Filotto
User development,
A new message was posted in the thread "How to manage empty data with a CacheLoader?":
http://community.jboss.org/message/524199#524199
Author : Nicolas Filotto
Profile : http://community.jboss.org/people/nfilotto
Message:
--------------------------------------------------------------
Hi Manik,
Thank you for your clear answer, actually we use JBC with a CacheLoader in that particular use case (which is in fact to implement the Lock Manager of our application) for the following requirements that are fulfilled by JBC with a CL :
1. The data of the locks must be replicated over the cluster
2. The data of the locks must not be modified at the same time to ensure their consistency (i.e 2 different users cannot add a lock on the same resource)
3. The data of the locks must be persisted
>> But if you know this set of keys and it is finite, then why do you use a cache store, since if it is to deal with persisting evicted objects, then you would still always have to check the store for existence of the object.
<< That is right, but all the data is loaded at startup, so we know that if the data is not in the local cache, it means that it doesn't exist in the database since the only way to add data into the database is to go though the JBC instance and its CacheLoader.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524199#524199
16 years, 2 months
[Javassist] New message: "Re: cannot access added Field in some cases. Please help."
by jaikiran pai
User development,
A new message was posted in the thread "cannot access added Field in some cases. Please help.":
http://community.jboss.org/message/524192#524192
Author : jaikiran pai
Profile : http://community.jboss.org/people/jaikiran
Message:
--------------------------------------------------------------
You haven't posted your complete code nor the complete exception stacktrace (i reason i keep insisting on these is because they can contain vital information). Anyway, i just gave a quick try against 3.11.0.GA version javassist:
public class NewFieldTestCase extends TestCase
{
public void testSharedInterfaceAndSuperClass() throws Exception
{
CtClass dummyClass = ClassPool.getDefault().get("org.myapp.test.javassist.Dummy");
CtField newIntField = new CtField(CtClass.intType,"myInt",dummyClass);
dummyClass.addField(newIntField);
CtMethod dummyMethod = dummyClass.getDeclaredMethod("dummyMethod");
dummyMethod.insertBefore("myInt = 10;");
byte[] modifiedDummyClassBytes = dummyClass.toBytecode();
assertTrue("Empty bytes", modifiedDummyClassBytes.length > 0);
}
}
Works fine. Test case passes, no exceptions thrown.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524192#524192
16 years, 2 months
[JBoss Cache] New message: "Re: How to manage empty data with a CacheLoader?"
by Manik Surtani
User development,
A new message was posted in the thread "How to manage empty data with a CacheLoader?":
http://community.jboss.org/message/524184#524184
Author : Manik Surtani
Profile : http://community.jboss.org/people/manik.surtani@jboss.com
Message:
--------------------------------------------------------------
This is a common problem with cache stores. If stuff isn't in memory there is every chance it is stored elsewhere and this must be checked.
Optimising the cache store will help to some degree, but if most of your threads result in cache misses, then you should rethink why you use a cache store (or even a cache!) in the first place.
Starting with optimisation, the JDBC cache store is one of the slowest, due to remote network connections and all sorts of bottlenecks in databases, combined with the fact that most databases need to be tuned extensively to start performing. One recommendation is to consider other forms of cache storage. BDBJE is a good engine, fast and powerful.
If you have to live with a JDBC backend, I recommend taking a look at Infinispan's JDBC cache store - a complete rewrite from the JBoss Cache one, and with some interesting optimisations in place that will help perform better. Note that Infinispan's JDBC cache store is not compatible with JBoss Cache, but you could enhance JBoss Cache's implementation using similar techniques.
But both of the above techniques just improve the performance of the cache store and not really solve your problem. Regarding your solution of using a "dummy entry", this does make sense provided you have a known and finite set of keys. But if you know this set of keys and it is finite, then why do you use a cache store, since if it is to deal with persisting evicted objects, then you would still always have to check the store for existence of the object.
Cheers
Manik
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524184#524184
16 years, 2 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
User development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524183#524183
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Apart from aop-mc-int since its tests are more complex than the others, I have got the tests running for all other modules in both modes in the branch. I had to adjust how dependency/OnDemandUnitTestCase and jmx-mc-int/NewOnDemandDependencyTest compare the expected install orders since the ordering with the new resolver is slightly different.
Also, I excluded the BadDependencyInfoTestCase from the indexing dependency resolver run since no matter how hard I try I just can't figure out what this test does :-) anyway it seems to depend on implementation details for the standard dependency resolver, so we will probably need a similar but different test for the indexing dependency resolver.
I tried booting up AS with the indexing dependency resolver enabled yesterday and it fell over, so I need to figure out why and try to test that as well as address the points in my previous post.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524183#524183
16 years, 2 months