[Design of JBossCache] - JBCACHE-1170
by bstansberry@jboss.com
Discussion of ongoing problems with http://jira.jboss.org/jira/browse/JBCACHE-1170 .
Possible cause, from org.jgroups.blocks.RequestCorrelator.handleRequest() through which all RPCs come:
| try {
| retval=request_handler.handle(req);
| }
| catch(Throwable t) {
| if(log.isErrorEnabled()) log.error("error invoking method", t);
| retval=t;
| }
|
| if(!hdr.rsp_expected) // asynchronous call, we don't need to send a response; terminate call here
| return;
|
| if(transport == null) {
| if(log.isErrorEnabled()) log.error("failure sending response; no transport available");
| return;
| }
|
| // changed (bela Feb 20 2004): catch exception and return exception
| try { // retval could be an exception, or a real value
| rsp_buf=marshaller != null? marshaller.objectToByteBuffer(retval) : Util.objectToByteBuffer(retval);
|
The first try block calls into the JBC code and ends up calling into the code that sets the CacheMarshaller200.regionForRemoteCall ThreadLocal.
Last try block again calls into the JBC response marshalling code, which clears the ThreadLocal.
Problem is the 2 return calls in between, particularly the 1st which will cause the method to return for every ASYNC RPC w/o clearing the ThreadLocal.
This is a private method, so there's no clean way to override it to ensure the TL is cleared.
Perhaps InactiveRegionAwareRpcDispatcher can clear the TL if the return value is null. That's a fragile mechanism to try to guesstimate what returns are possibly async. Mostly just a cleanup attempt.
A separate question is why the partial state transfer call isn't setting the TL to the correct value. Ah, right, it's not RPC based so the state transfer request doesn't go through the marshaller.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137144#4137144
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137144
18 years
[Design of JBoss jBPM] - Re: New jBPM Console
by brittm
So much can be gained (and proven) using an EJB3 stack, that I can't think of a good reason not to. Three thoughts:
* The jBPM/SEAM/Jboss community should be looking for opportunities to demonstrate all these offerings really working together on a modern EJB3 platform. Red Hat/Jboss needs to show the industry that its solutions are modern and to take the lead in demonstrating best-practices in the implementation of its leading technologies.
* Implementing against EJB3 would be more likely to identify bugs and needed enhancements in up-stream projects--doing more to both improve the upstream projects and provide a greater pool of solid, working examples of utilizing these technologies in a modern framework.
* Process management is such an "enterprise" type of application, that requiring a modern container seems quite reasonable.
* Negatives might be any known issues with EJB3 that would hamper delivery of a solid product. (But I don't know of any, so someone else will have to speak about that.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137143#4137143
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137143
18 years
[Design the new POJO MicroContainer] - Moving to CR1 releases of the MC projects
by adrian@jboss.org
In an effort to try to get the codebase stable I want to move to more
frequent releases of the betas with the codebase in an easy integratable state
into JBossAS.
If we think a beta is stable then we can move it to an CR1 meaning there
will be no more new features (however minor), just bug fixes.
So starting from this week, I'm going to be doing beta releases on Fridays
of the MC projects if they have changes during the week.
These are the main projects used by the AS that I'm responsbile for at the moment,
i.e. not VFS, managed, reliance, OSGI
With that in bind, JIRA needs updating with what we think will be done end of
Thursday. Friday will be testing and bug fixing only until I've got the releases out. :-)
I'll be spending most of my time testing and fixing the AS anyway.
Anything that doesn't make it must be reverted and done again in the next week,
so plan accordingly.
(if we move to project to a CRx then I'll create a branch such that new
development/features can continue in trunk).
I'm hoping we can get to CRx/GA releases very quickly,
hopefully within a couple of weeks?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137140#4137140
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137140
18 years
[Design of POJO Server] - Fixing the WarClassLoaderDeployer
by adrian@jboss.org
The current way the WarClassLoaderDeployer works is all of the place. :-)
INCLUDE WEB-INF
I thought the requirement was to include the root of the war
since that is what the old UCL did?
Anyway this should be in the structure deployer not the classloader deployer.
Same goes for some of the other flags, is "acceptNonWarDirs" still used?
COPYING TO TEMP
Again this should be in the structure deployer. The VirtualFiles is adds
should be the temp ones.
ALT-DD
This doesn't look like it is handled properly in the new deployers?
Shouldn't this be handled in the metadata parsing?
PLAYING AROUND WITH METADATA
The merging and altering of metadata shouldn't be left to the "RealDeployer"
i.e. AbstractWarDeployer. Doing so means it cannot be overridden
by some other policy.
What's most annoying is that bad examples like this are being used
by the other people as the correct way to do things :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137137#4137137
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137137
18 years