[Design of POJO Server] - JBAS-6104; slow Seam deployments
by alesj
Moving the https://jira.jboss.org/jira/browse/JBAS-6104 discussion here.
Instructions to re-produce error:
"Jozef Hartinger" wrote :
| I have encountered strange behaviour of AS when testing Seam 2.0.3.CR1 recently. To reproduce follow these steps:
| a) deploy Seam booking example
| b) some interaction is needed so book some hotel
| c) undeploy Seam booking example
| d) deploy Seam drools example
| example starts to deploy but at some point it hangs and looks like nothing is happening - no messages being appended in log not even debug messages however I noticed heavy disk usage. Usualy after waiting more than 10 minutes second example is still not deployed. It happens in both Seam 2.0.3.CR1 and Seam 2.1.0.CR1. Same situation with registration and itext example. Issue may be caused by problem with undeploying the first example. in some cases second example gets deployed after several minutes.
Stan is able to re-produce it with different set of Seam examples:
"Stan Silvert" wrote :
| I took a look at this. I used numberguess instead of drools, but followed the same steps above.
| What I found was that numberguess does eventually get deployed and will work properly if you wait about 5 minutes after step d).
|
| I guess something needs to time out. It's definitely weird behavior.
Shane's investigation begins. :-)
"Shane Bryzak" wrote :
| Not much progress on this so far, I got to step c, undeploying the booking example which worked however threw some exceptions during undeployment. I then tried to deploy the drools example, which cause the app server to just sit there grinding the hard disk for at least 30 minutes (with no successful deploy).
|
| I'm currently building the latest trunk of JBossAS so that I have something a little more recent to test against.
|
"Shane Bryzak" wrote :
| Ok not looking much better on latest trunk either.. the HotDeployFilter bug is still happening (every single request is resulting in a full redeploy) and it's generally running dog slow. I'll spent some time profiling to try and nail down some more specific details.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182834#4182834
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182834
17 years, 5 months
[Design of EJB 3.0] - Runtime Metadata View
by ALRubinger
This is one we've known about for some time, and I'd like to get a definitive plan together and stick to it.
The metadata provided by jboss-metadata does not account for an AspectDomain (ie. information that may have been tacked on by AOP), and right now we've got two models:
* EJB3 Core (container.getAnnotation(MyAnnotation.class)
* jboss-metadata (myMetaData.getMyAnnotation());
In EJB3 Proxy I'm using the jboss-metadata model, which due to being an incomplete view, regresses the EJB3 TestSuite "defaultremotebindings" for example.
<!-- This is not available in JBossSessionBeanMetaData presently -->
| <annotation expr="!class((a)org.jboss.ejb3.annotation.RemoteBinding)">
| @org.jboss.ejb3.annotation.RemoteBinding (jndiBinding="DefaultedStateless", factory = "RemoteProxyFactory", interceptorStack="", clientBindUrl = "")
| </annotation>
I'll propose the following:
* Build out the MetaData Bridge started by Carlo in jboss-ejb-metadata
* Convert "getAnnotation"-style semantics to use direct metadata as we come across bug fixes, refactorings.
* Create Deployer to apply the MetaData Bridge to JBossMetaData.isEjb3x()
This has the following benefits:
* Doesn't force refactoring/changing of old (working) mechanisms
* Allows stuff using jboss-metadata view to stay intact without any changes
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182806#4182806
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182806
17 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: new QueueBrowser implementation
by timfox
I just had a quick look at the latest code just checked in, and I have a few questions:
1) Why are the methods stop, start, restart, and the extra logic around "messagesWaiting", and the extra server consumer start and stop necessary in the ClientBrowserImpl?
Shouldn't the browsing consumer just behave exactly like a normal consumer?
2) On the server side, the method deliver and DeliverRunner class has been added to the the ServerConsumerImpl, which duplicates code already in the QueueImpl.
A simpler solution would have been to take the copied Set of refs from the queue.list() method, and then instantiate a QueueImpl instance on the fly and just have the consumer consume from that, or create a simple class that just iterates the set and get it to call the handle() method of ServerConsumer, then you wouldn't need to duplicate the code.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182764#4182764
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4182764
17 years, 5 months