[Design the new POJO MicroContainer] - Re: Concurrent deployments
by david.lloyd@jboss.com
"adrian(a)jboss.org" wrote : * Not all services define their dependencies properly. It's only the implicit sequential order that makes them work correctly.
If they don't define their dependencies properly, what guarantee is there that they will even work at all?
"adrian(a)jboss.org" wrote : * Finally, less of a practical issue, but more a generic note. Using mulitple threads for startup will only work if there are multiple cpus/cores. In non SMP environments the bootstrap could be slower with multiple competing threads, although it may be able to take advantage of times during disk I/O waits
| to do some processing on other threads?
Two things - first, I don't even know where I'd be able to buy a server-class system (heck even a desktop-class system come to think of it) that didn't have at least two cores (if not two or more multi-core CPUs). But that issue aside, any service that has non-CPU bound tasks (which includes not just disk I/O but network I/O) could possibly see a performance benefit from concurrent startup, even on a single-core system. And in any case we're talking about service deployment - I doubt the additional overhead of context switching between multiple threads could possibly make a measurable impact on performance. Especially in comparison to examples like Bela's 5-second timeout.
Also one could reasonably expect that rather than firing off a thread for every task, there would be a thread pool Executor of some sort. The thread pool could be sized in proportion to the number of cores available, or in some configurable fashion. Then the simple rule would be, any deployment task with no remaining dependencies gets put into the queue for execution.
I don't really understand the hairy details behind some of the classloader problems, but surely they could be worked around by imposing some reliance on the dependency system for them as well?
I agree with Bela - a concurrent startup would be hugely beneficial for startup time, not to mention just being cool. In fact when first learning about the MC and its dependency system, I had simply assumed that dependencies were resolved concurrently and never gave it a moment's thought. It wasn't until I spoke with Bela at JBW that I learned otherwise.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131491#4131491
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131491
18 years, 1 month
[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use
by adrian@jboss.org
"scott.stark(a)jboss.org" wrote : "adrian(a)jboss.org" wrote :
| | I suppose I could validate the capabilities that say they "ExportPackages"
| | by running the ExportALL processing even if you explicitly list the package capabilities,
| | but I'm not sure it really buys much?
| | You'll still get a ClassNotFoundException on javax.jms.Queue
| | if you export the package, include it in your filesystem but don't have that class. ;-)
| Right, but what we want to be able to debug is the question about why javax.jms.Queue is not found when it sitting in my-jms.jar of classloader x. Its going to be common to have classes from the server domain hidden from the application deployment class loader, so why the hidden class is not seen in the question.
|
The management interface of the classloader will show the package is not exported,
but you'd need to see the filter(s) and decode them to understand why.
I guess I could always add some more trace logging to say which filter excludes a package? :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131488#4131488
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131488
18 years, 1 month
[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu
by anil.saldhana@jboss.com
"scott.stark(a)jboss.org" wrote : The problem is the use of metaData.getClass().getName() as this returns the implementation class. You need to use JBossAppMetaData.class.getName() since that is the signature. Its the metaData instance that has to be an implementation of this. The ctor parameters also look incorrect that it should be metaData rather than deployment:
|
|
| | ServiceConstructorMetaData serviceConstructor = new ServiceConstructorMetaData();
| | serviceConstructor.setSignature(new String[] { String.class.getName(),
| | JBossAppMetaData.class.getName(),Boolean.class.getName()});
| | serviceConstructor.setParameters(new Object[] {contextId, metaData, Boolean.TRUE});
| | createJaccPolicyBean(serviceConstructor, unit);
| |
|
That is the change I am doing now. Rather than the use of metaData.getClass().getName(), I am doing getMetaDataClassType() which is an overridden method in the sub-deployers (EarSecurityDeployer will pass JBossAppMetaData as the meta data class type).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131485#4131485
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131485
18 years, 1 month