April 2008 - jboss-dev-forums - Jboss List Archives

[Design of the JBoss EJB Container] - NoManagedConnections

by junm22

we always got this error please help :) org.jboss.util.NestedSQLException:NoManagedConnections available within configured blocking timeout (80000[ms]); - nested throwable: (javax.resource.ResourceException: NoManagedConnections available within configured blocking timeout ((80000[ms])). our system is also slowing and eventually hang please help anyone there View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143352#4143352 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143352

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Anonymous beans

by bstansberry＠jboss.com

There's a problem with the way the anonymous bean impl (NestedBeanHandler I think) is generating names. Looks like it's getting confused about where it is in the nested bean hierarchy and ends up trying to apply the same name to multiple beans. The -beans.xml I'm trying to deploy can be found at https://svn.jboss.org/repos/jbossas/trunk/cluster/src/etc/jboss-cache-man... . When I try to deploy it in AS trunk I get this: | 2008-04-10 22:45:20,150 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Real: name=vfsfile:/home/bes/dev/jboss/trunk/build/output/jboss-5.0.0.CR1/server/all/deploy/cluster/jboss-cache-manager-beans.xml state=PreReal mode=Manual requiredState=Real | org.jboss.deployers.spi.DeploymentException: Error deploying: CacheConfigurationRegistry$runtimeConfig | at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) | at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:92) | at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:46) | at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) | at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) | at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:991) | at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1394) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:786) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:914) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:836) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:674) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:456) | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594) | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:259) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:137) | at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409) | at org.jboss.Main.boot(Main.java:209) | at org.jboss.Main$1.run(Main.java:544) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.IllegalStateException: CacheConfigurationRegistry$runtimeConfig is already installed. | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:577) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:443) | at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:88) | ... 22 more | Note that the runtimeConfig property is not an immediate child of the CacheConfigurationRegistry bean. It's a property of "StandardSessionCacheConfig" and "FieldSessionCacheConfig". To add to the challenge, "StandardSessionCacheConfig" and "FieldSessionCacheConfig" really can be anonymous. I just gave them names for human readability. So any solution should work even if they were anonymous. BTW, what I'm trying to do in the part of this file that uses anonymous beans is parse XML to create a set of JBoss Cache configurations. JBC has its own XML format and parser that I can use to accomplish this. It didn't have system property substitution, but I added that earlier this week. So I can use that. I'd prefer to use MC to do this. But don't let me totally rearrange your schedule; I have a workaround. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143341#4143341 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143341

17 years, 12 months

1
0
0 / 0

[Design of POJO Server] - LogConfigurationException from commons-logging

by bstansberry＠jboss.com

I've been seeing this kind of thing quite a bit in logs from testsuite runs; seems to correspond to intermittent increase in clustering failures: | 2008-04-10 13:58:28,949 ERROR [org.jboss.cache.remoting.jgroups.CacheMessageListener] (Multiplexer,udp,10.18.34.175:51700) Caught org.apache.commons.logging.LogConfigurationException while responding to state transfer request | org.apache.commons.logging.LogConfigurationException: User-specified log class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or is not useable. | at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:798) | at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601) | at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333) | at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:664) | at org.jboss.cache.statetransfer.DefaultStateTransferGenerator.<init>(DefaultStateTransferGenerator.java:32) | at org.jboss.cache.statetransfer.StateTransferFactory.getStateTransferGenerator(StateTransferFactory.java:43) | at org.jboss.cache.statetransfer.StateTransferManager.getStateTransferGenerator(StateTransferManager.java:297) | at org.jboss.cache.statetransfer.StateTransferManager.getState(StateTransferManager.java:82) | at org.jboss.cache.remoting.jgroups.CacheMessageListener.getState(CacheMessageListener.java:137) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:629) | at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:747) | at org.jgroups.JChannel.up(JChannel.java:1154) | at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1175) | at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1198) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | at java.lang.Thread.run(Thread.java:595) | I'm going to turn on commons-logging's diagnostic logging feature for the cluster-udp-0 and cluster-udp-1 configs; hopefully that will shed some light on what's causing this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143331#4143331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143331

17 years, 12 months

1
0
0 / 0

[Design of JBoss Build System] - Next steps of mavenizing app server

by pgier

Now that the mavenized build thirdparty seems to be working ok, I would like to gradually replace more parts of the ant build with maven. I'm thinking this could be done one or two modules at a time until they are all using maven. So for example, the module "main" is normally the first to run in the app server build. So I will try to have the main build file call the maven build just for this module before running the rest of the modules with the normal ant build. This should allow the integration to happen more gradually so that I can work on one or two issues at a time instead of trying to replicate the whole thing at once. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143321#4143321 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143321

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC facade / fancy handles

by alesj

"adrian(a)jboss.org" wrote : | * Use the MC directly as the implementation detail of the locator | It's this one that needs to be pimped even more. :-) But the question was more 'where' to put this than what/how. And /dev/null or /dev/random is not appripriate. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143311#4143311 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143311

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by clebert.suconic＠jboss.com

All the test does is send and receive messages. Those methods were used before the call that caused the failure. At the time the message is taking more time to perform a send call, the pseudo internal class on AOP should be already generated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143268#4143268 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143268

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC facade / fancy handles

by adrian＠jboss.org

You're talking about old IOC style programming i.e. registry.getBean(name); I don't like this form of IOC since it means you are tied to the container api and therefore not portable across IOC containers. It should be discourged. The best way to get the bean is to inject it. :-) But if you are going to do it, then you're better off using something like the locator pattern examples I did in the initial user guide. Either: * Use the MC to build up a singleton hashtable name->object http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... * Use the MC directly as the implementation detail of the locator http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143262#4143262 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143262

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by flavia.rainone＠jboss.com

I'll take a look. My bet is that the lazy generation of classes is affecting your test performance. The default instrumentation mode generates classes only when the affected joinpoint are executed for the first time. On the other hand, the classical instrumentation does not generate any classes in this moment... everything is generated during aopc execution solely. I'll let you know when I have a better answer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143261#4143261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143261

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by clebert.suconic＠jboss.com

Being more specific org.jboss.test.messaging.jms.clustering.DistributedQueueTest is failing with default instrumentation and passing with classic. to test it you could either use runtest or: cd ./test ant -Dtest-mask=DistributedQueueTest clustering-tests compile-report Something is taking more time when we send a message. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143260#4143260 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143260

17 years, 12 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by clebert.suconic＠jboss.com

There is one issue with the default aopc. We have few tests that are time sensitive, testing things like expiration time.. things like that. Those tests are failing with the default aopc and passing with the ClassicVersion. That makes suspect that there is some performance issue (maybe excessive classLoader) with the newer version. You should investigate. >From our side I will keep using the Classic when calling aopc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143258#4143258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143258

17 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008