[JBoss JIRA] Created: (JGRP-484) Dynamically configure logging at runtime
by Bela Ban (JIRA)
Dynamically configure logging at runtime
----------------------------------------
Key: JGRP-484
URL: http://jira.jboss.com/jira/browse/JGRP-484
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.4.1 SP3, 2.5
For performance reasons, JGroups caches log levels as follows:
boolean trace=log.isTraceEnabled();
// later:
if(trace) {
log.trace(...);
}
While caching created a measurable performance increase, it also disabled the ability to change the log levels at runtime (example: JBoss' log4j.xml, which is re-read every 60 secs).
Investigate how to have both good performance and dynamic runtime configuration of log levels. E.g. signal to enable logging ?
--
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
19 years, 3 months
[JBoss JIRA] Created: (JGRP-486) UNICAST: messages not retransmitted on load
by Bela Ban (JIRA)
UNICAST: messages not retransmitted on load
-------------------------------------------
Key: JGRP-486
URL: http://jira.jboss.com/jira/browse/JGRP-486
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4.1 SP3, 2.5
To reproduce, run JBento in the ATL lab with 6 instances, then run Brian's stress test (3 instances with a total of 3000 threads).
This only occurs with buddy replication (which uses UNICAST), it doesn't occur with NAKACK. Also, it doesn't occur with TCP as transport (so that's a workaround).
Let's say we have buddies A and B.
After some time, B's UNICAST AckReceiverWindow for A shows next_to_remove=80265, msgs=[80266-82139]. This means that we expect 80265 as next seqno, however the lowest seqno we've received is 80266. The window gets new messages every 5 secs (credit requests from A), and adds them. But it cannot deliver them as it hasn't received 80265 yet !
A's UNICAST AckSenderWindow for B shows 1 message in the retransmission queue: 80265. The stack trace shows that the timer thread is still running (waiting for tasks to execute), but for some reason, 80265 is never retransmitted to B ! We don't see a retransmit() method in the TRACE logs (we do see the other UNICAST methods invoked, e.g. DATA and ACK traces).
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3865) Recursive loop on shutdown
by Scott M Stark (JIRA)
Recursive loop on shutdown
--------------------------
Key: JBAS-3865
URL: http://jira.jboss.com/jira/browse/JBAS-3865
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: MicroContainer bus
Reporter: Scott M Stark
Assigned To: Adrian Brock
Fix For: JBossAS-5.0.0.Beta2
When shutting down the server mid startup after an error I have seen the server get into a state where it loops on this type of error:
09:29:21,803 ERROR [AbstractKernelController] INTERNAL ERROR: context not found in previous state Installed context=name=EJB3EntityCacheConfig state=Installedjava.lang.Exception: STACKTRACE
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:638)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.stop(ServiceController.java:481)
at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:131)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:111)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:60)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:105)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:419)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:428)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:357)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:482)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:739)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:721)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:706)
09:29:21,906 ERROR [AbstractKernelController] INTERNAL ERROR: context not found in previous state Installed context=name=EJB3EntityCacheConfig state=Installedjava.lang.Exception: STACKTRACE
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:638)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.stop(ServiceController.java:481)
at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:131)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:111)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:60)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:105)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:419)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:428)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:357)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:482)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:739)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:721)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:706)
09:29:21,906 ERROR [AbstractKernelController] INTERNAL ERROR: context not found in previous state Installed context=name=EJB3EntityCacheConfig state=Installedjava.lang.Exception: STACKTRACE
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:638)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.stop(ServiceController.java:481)
at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:131)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:111)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:60)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:105)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:419)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:428)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:357)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:482)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:739)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:721)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:706)
A kill -9 is required to stop it after this.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBRULES-627) null pointer with number comparison..
by Sachin Holla (JIRA)
null pointer with number comparison..
-------------------------------------
Key: JBRULES-627
URL: http://jira.jboss.com/jira/browse/JBRULES-627
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.0.4
Environment: Windows XP or Solaris
Sun JDK 1.4.2
Drools 3.0.4 distribution
Reporter: Sachin Holla
Assigned To: Mark Proctor
getting a null pointer while asserting fact:
Caused by: java.lang.NullPointerException
at org.drools.base.evaluators.IntegerFactory$IntegerGreaterEvaluator.evaluate(Unknown Source)
at org.drools.rule.BoundVariableConstraint.isAllowed(Unknown Source)
at org.drools.common.BetaNodeBinder.isAllowed(Unknown Source)
at org.drools.reteoo.TupleSource.attemptJoin(Unknown Source)
at org.drools.reteoo.JoinNode.assertTuple(Unknown Source)
at org.drools.reteoo.LeftInputAdapterNode.createAndAssertTuple(Unknown Source)
at org.drools.reteoo.LeftInputAdapterNode.assertObject(Unknown Source)
at org.drools.reteoo.ObjectSource.propagateAssertObject(Unknown Source)
at org.drools.reteoo.ObjectTypeNode.assertObject(Unknown Source)
at org.drools.reteoo.Rete.assertObject(Unknown Source)
at org.drools.reteoo.ReteooRuleBase.assertObject(Unknown Source)
at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(Unknown Source)
at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source)
at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source)
Rule is something like this:
rule "Greater Than with NULL number!!"
when
MyFact ( integerAttribute > 10 )
then
.....
end
the *intergerAttribute* is of type java.lang.Integer and value is *null*.
no such problem if expression changed to *integerAttribute == 10* or !=
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBPORTAL-1350) NPE when adding a security constraint to a portal
by Adam Warski (JIRA)
NPE when adding a security constraint to a portal
-------------------------------------------------
Key: JBPORTAL-1350
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1350
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Security
Affects Versions: 2.6.Beta1
Reporter: Adam Warski
Assigned To: Julien Viet
Fix For: 2.6.CR1
Adding the following security constraint to portal-object.xml, in the "default" portal:
<security-constraint>
<policy-permission>
<action-name>view</action-name>
<unchecked />
</policy-permission>
</security-constraint>
causes the following exception, when opening the main portal page:
01:14:43,019 ERROR [PortalServlet] Unexpected exception
java.lang.NullPointerException:
at org.jboss.portal.server.impl.ServerInvocationContextImpl$Buffer.toString(ServerInvocationContextImpl.java:256)
at org.jboss.portal.server.impl.ServerInvocationContextImpl.renderURL(ServerInvocationContextImpl.java:202)
at org.jboss.portal.server.ServerResponse.renderURL(ServerResponse.java:101)
at org.jboss.portal.core.controller.classic.ThrowableResponseHandler.processCommandResponse(ThrowableResponseHandler.java:66)
at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processHandlers(ClassicResponseHandler.java:96)
at org.jboss.portal.core.controller.classic.ClassicResponseHandler.processCommandResponse(ClassicResponseHandler.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy133.processCommandResponse(Unknown Source)
at org.jboss.portal.core.controller.ResponseHandlerSelector.processCommandResponse(ResponseHandlerSelector.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-4286) users.properties file not being correctly located in CustomSecurityManagerTestCase
by Richard Achmatowicz (JIRA)
users.properties file not being correctly located in CustomSecurityManagerTestCase
----------------------------------------------------------------------------------
Key: JBAS-4286
URL: http://jira.jboss.com/jira/browse/JBAS-4286
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-4.2.0.CR1
Environment: Windows 2003, x86_64, x86, BEA JVM
Reporter: Richard Achmatowicz
Assigned To: Scott M Stark
Attachments: server.log
The following tests are failing due to a common error:
testGetCallerPrinciple, testStatefulCreateCaller, testMethodAccess, testDomainMethodAccess
testMethodAccess2, testLocalMethodAccess, testUncheckedRemote, testRemoteUnchecked, testUnchecked
testUncheckedWithLogin, testExcluded, testRunAs, testDeepRunAs
and others
The common error is:
Suite: org.jboss.test.security.test.CustomSecurityManagerTestCase(custom-secmgr)
Test: testDomainMethodAccess
Type: error
Exception: java.rmi.AccessException
Message: SecurityException; nested exception is: javax.security.auth.login.LoginException: Missing users.properties file.
---------------------------------
The test case CunstomSecurityManagerTestCase is a subclass of the test case EJBSpecUnitTestCase.
EJBSpecUnitTestCase deploys the jar security-spec.jar which contains users.properties and roles.properties files, but these seem not to be located.
>From the output.log, it seems that the security-spec.jar is not being deployed before the custom-secmgrtests.ear. I have attached the log.
--
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
19 years, 3 months