[JBoss JIRA] Created: (JBAS-4871) TransactionIsolation is not reset when Connection is returned to the pool
by Diego Belfer (JIRA)
TransactionIsolation is not reset when Connection is returned to the pool
-------------------------------------------------------------------------
Key: JBAS-4871
URL: http://jira.jboss.com/jira/browse/JBAS-4871
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.5.GA
Reporter: Diego Belfer
TransactionIsolation is not being reset when the JDBC connection is returned to the pool. Bug is indicated in the code.
This was also reported in http://jira.jboss.com/jira/browse/JBAS-1123 and marked as closed but the bug is still there.
public void cleanup() throws ResourceException
{
synchronized (handles)
{
for (Iterator i = handles.iterator(); i.hasNext(); )
{
WrappedConnection lc = (WrappedConnection)i.next();
lc.setManagedConnection(null);
}
handles.clear();
}
//reset all the properties we know about to defaults.
synchronized (stateLock)
{
jdbcAutoCommit = true;
jdbcReadOnly = readOnly;
if (jdbcTransactionIsolation != transactionIsolation)
{
try
{
con.setTransactionIsolation(jdbcTransactionIsolation); <-- BUG: It should be con.setTransactionIsolation(transactionIsolation);
jdbcTransactionIsolation = transactionIsolation;
}
catch (SQLException e)
{
mcf.log.warn("Error resetting transaction isolation ", e);
}
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Created: (JBPORTAL-1324) Multiple portals / custom url : set the default portal name
by Antoine Herzog (JIRA)
Multiple portals / custom url : set the default portal name
-----------------------------------------------------------
Key: JBPORTAL-1324
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1324
Project: JBoss Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Portal Core
Environment: JBoss Portal 2.4.0 final
Reporter: Antoine Herzog
Assigned To: Julien Viet
Here the code of the jmx service class
public class ConfigurableDefaultPortalCommandFactory extends
DefaultPortalCommandFactory {
private static final Log logger = LogFactory
.getLog(ConfigurableDefaultPortalCommandFactory.class);
/**
* The JMX attribute for default portal name.
*/
private String defaultPortalName;
/**
*
*/
public ConfigurableDefaultPortalCommandFactory() {
super();
}
/*
* (non-Javadoc)
*
* @see org.jboss.portal.core.model.portal.DefaultPortalCommandFactory#doMapping(org.jboss.portal.server.ServerInvocation,
* java.lang.String, java.lang.String)
*/
public ControllerCommand doMapping(ServerInvocation invocation,
String portalContextPath, String portalRequestPath) {
// orginal code : ControllerCommand cmd =
// nextFactory.doMapping(invocation,
ControllerCommand cmd = getNextFactory().doMapping(invocation,
portalContextPath, portalRequestPath);
if (cmd == null) {
// orginal code : Context ctx = container.getContext();
Context ctx = getContainer().getContext();
if (ctx == null) {
throw new IllegalStateException(
"Default context does not exist");
}
// orginal code : Portal portal = ctx.getDefaultPortal();
PortalObject portalObject = ctx.getChild(getDefaultPortalName());
if (portalObject == null) {
throw new IllegalStateException(
"PortalObject as Default Portal is not found. Default Portal name is defined to : "
+ getDefaultPortalName());
}
Portal portal = null;
if (portalObject instanceof Portal) {
portal = (Portal) portalObject;
} else {
throw new IllegalStateException(
"Can't find PortalObject with default portal name : "
+ getDefaultPortalName());
}
// if (portal == null) {
// throw new IllegalStateException("Default portal does not exist");
// }
Page page = portal.getDefaultPage();
if (page == null) {
throw new IllegalStateException("Default page does not exist");
}
String handle = page.getId();
cmd = new RenderPageCommand(handle);
}
return cmd;
}
/**
* The JMX attribute for default portal name.
*
* @return the defaultPortalName
*/
public String getDefaultPortalName() {
return this.defaultPortalName;
}
/**
* The JMX attribute for default portal name.
*
* @param defaultPortalName
* the defaultPortalName to set
*/
public void setDefaultPortalName(String defaultPortalName) {
this.defaultPortalName = defaultPortalName;
}
/**
* Call the super method first, then check the {@link #defaultPortalName} is
* not null and not "". Throw an exception if so.
*/
protected void createService() throws Exception {
super.createService();
if (getDefaultPortalName() == null
|| getDefaultPortalName().compareTo("") == 0) {
throw new Exception(
"The attribute DefaultPortalName can't be null or empty string. Set it in the JMX service descriptor.");
}
}
/*
* (non-Javadoc)
*
* @see org.jboss.system.ServiceMBeanSupport#startService()
*/
@Override
protected void startService() throws Exception {
logger.info(this.getName() + " service starting. Default portal name : getDefaultPortalName() = "+getDefaultPortalName());
super.startService();
}
/*
* (non-Javadoc)
*
* @see org.jboss.system.ServiceMBeanSupport#stopService()
*/
@Override
protected void stopService() throws Exception {
super.stopService();
logger.info(this.getName() + " service stoping.");
}
}
And add the attribute in the jmx service descriptor :
<!-- Default portal name : "default" is the default for native jboss portal (downloaded version). -->
<attribute name="DefaultPortalName">MyDefaultPortalNameHere</attribute>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Created: (JBAS-3654) The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
by Sakthi Samabsivam (JIRA)
The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
----------------------------------------------------------------------------
Key: JBAS-3654
URL: http://jira.jboss.com/jira/browse/JBAS-3654
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.3RC2, JBossAS-4.0.3RC1
Reporter: Sakthi Samabsivam
Assigned To: Dimitris Andreadis
When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
for example. I have two ears example1. ear and example2.ear.
I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
So I am wrting this depends tag entry in my example1.ear's WAR compoent jboss-web.xml
<depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
This depends is working till jboss 4.0.1
It fails in 4.0.3 SP1 , 4.0.4 GA
15:52:24,359 WARN [ServiceController] Problem starting service jboss.web.deploy
ment:war=crimeportal.war,id=-1360680885
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
e: (javax.security.jacc.PolicyContextException: Operation not allowed)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
at org.jboss.web.WebModule.startModule(WebModule.java:68)
at org.jboss.web.WebModule.startService(WebModule.java:46)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:428)
at org.jboss.system.ServiceController.start(ServiceController.java:446)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy21.start(Unknown Source)
at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:319)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:507)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:192)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:265)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:428)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
at org.jboss.Main.boot(Main.java:187)
at org.jboss.Main$1.run(Main.java:438)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:201)
at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
ossPolicyConfiguration.java:160)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
... 94 more
Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
tion: linkConfiguration from state:inService
at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:196)
... 96 more
15:52:24,359 INFO [EARDeployer] Started J2EE application: file:/C:/jboss/traini
ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- MBeans waiting for other MBeans ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
I Depend On:
jboss.j2ee:url='FiboApp.ear',service=EARDeployment
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
I Depend On:
jboss.j2ee:url='FiboApp.ear',service=EARDeployment
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Created: (JBAS-4586) unified invoker causes delays under load
by Troy Bowman (JIRA)
unified invoker causes delays under load
----------------------------------------
Key: JBAS-4586
URL: http://jira.jboss.com/jira/browse/JBAS-4586
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Remoting
Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
Environment: Linux kernel 2.6.21, Java 1.5.0_12, JBoss 4.2.0.GA
Reporter: Troy Bowman
Assigned To: Ron Sigal
We tested Jboss 4.2.0.GA and found it worthy for production. When we actually did put it in production, and more than about 300 people were using the application simultaneously, people complained that the application was extremely slow. Some commands, which issued several rmi invocations, would take several minutes. There was not a heavy load on the servers, however. It seemed like every request was just waiting for something to timeout, or that something was causing deadlock in a synchronized block.
I analyzed the problem by both watching the jboss server.log, and also using tcpdump to watch network traffic. I noticed big pauses where neither the server, client, or network was doing anything at all. I made tcpdump have a zero snaplen and read through each packet trying to find what exactly it was doing. I followed the process from ports 1099(naming) to 1098(rmi) to 4446(unified invoker). Right when the client would invoke the stub it had from rmi, it'd sit there for 12 to 14 seconds. I looked at this from other commands and indeed, it was waiting for the invoker.
I started googling for hangs with the jboss invoker and stumbled across some bugs, and found these:
http://jira.jboss.org/jira/browse/JBREM-203?decorator=printable
http://jira.jboss.org/jira/browse/JBREM-167?page=all&decorator=printable
http://jira.jboss.com/jira/browse/JBREM-165;jsessionid=4A6E5196E7A1A78EAF...
They're all old bugs, but at least it is obvious that the unified invoker had problems in the past with hanging while marshalling/unmarshalling with jboss's custom (un)marshallers. My suspicion was that they may have solved the problem with the hack back then, but it is probably showing its ugly head when the server is under a heavy load.
In searching for more stuff, I found that the readme for jboss-4.2.0.GA said that "The default invoker for EJBs has been changed from the rmi-invoker to the unified-invoker, provided by JBoss Remoting". This got me very susupicious of it, since it was definitely the invoker that was sitting there for around 15 seconds on every request when the server had a heavier load. I looked at the change to the standardjboss.xml:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/branches/Branch_4_2/se...
I changed the proxy bindings from the unified invoker back to the rmi invoker in standardjboss.xml, and the problem went away. Invocations now go through port 4444, and are instantaneous.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months