[JBoss JIRA] Created: (JBMESSAGING-789) Non causality when using Remoting socket transport and one way invocations
by Tim Fox (JIRA)
Non causality when using Remoting socket transport and one way invocations
--------------------------------------------------------------------------
Key: JBMESSAGING-789
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-789
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.2.0.Beta1
Reporter: Tim Fox
Priority: Critical
Fix For: 1.2.0.CR1
The remoting socket transport uses an underlying pool of tcp connections, and subsequent invocations get a connection from the pool, use it and return it from the pool.
This means that subsequent invocations can use a different underlying TCP connection, and later invocations can overtake earlier ones depending on how the OS schedules the read threads listening on the connections.
Temporary work around is to use a pool size of 1, or completely serialize all invocations per VM by encloing in the synchronized block. This gives us effectively one TCP connection per VM.
A better approach would be for the remoting Client object to be pinned to the actual TCP connection one to one. I.e. we don't want or need the pool. It is just a big PITA for us.
--
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, 1 month
[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, 2 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, 2 months
[JBoss JIRA] Created: (JBPORTAL-1175) Provide security authentication per wsrp producer in the consumer
by Julien Viet (JIRA)
Provide security authentication per wsrp producer in the consumer
-----------------------------------------------------------------
Key: JBPORTAL-1175
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1175
Project: JBoss Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Portal WSRP
Reporter: Julien Viet
Assigned To: Chris Laprun
Fix For: 2.6.Beta1
Security based on SOAP/HTTP security which allow basic/digest authentication.
Usually the stub can be configured using smth like :
Stub stub = // ... get the Stub;
stub._setProperty ("javax.xml.rpc.security.auth.username", "juliet");
stub._setProperty ("javax.xml.rpc.security.auth.password", "mypassword");
We need to support several kind of username/password style, so we should have
1/ a global username/password for the whole producer, smth like
<wsrp-producer>
<producer-id>blah</producer-id>
...
<auth-config>
<username>blah username</username>
<password>blah password</password>
</auth-config>
</wsrp-producer>
2/ a generic mechanism that would allow more fine grained username/password that can allow to make identity propagation (for sso)
<wsrp-producer>
<producer-id>blah</producer-id>
...
<auth-config>
<credential-factory>org.client.BlahCredentialFactory</credential-factory>
</auth-config>
</wsrp-producer>
with an interface which allows to retrieve credentials. Usually the factory implementations leverage thread local mechanisms to integrate the user identity with a username/password storage like :
String userId = UserId.getCurrentUserId();
String password = passwordStore.getPassword(userId);
return new WSRPCredential(userId, password);
--
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, 2 months
[JBoss JIRA] Created: (JBPORTAL-1239) page level security not honored in the navigation system
by Stephen Westbom (JIRA)
page level security not honored in the navigation system
--------------------------------------------------------
Key: JBPORTAL-1239
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1239
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Security
Affects Versions: 2.6.Alpha2
Environment: Windows XP
Reporter: Stephen Westbom
Assigned To: Julien Viet
In 2.4 sp1 pages are checked for security before being displayed as a tab in the navigation using this jsp:
jboss-portal.sar\portal-core.war\WEB-INF\jsp\catalog\index.jsp
This seems to be handled by the psib request parameter (a map). In 2.4 the map only gives you PortalNodeURLs that you have permissions on, in all the 2.6 versions you get all the siblingURLs (your term in the JSP page) regardless of the permission settings in the {project name}_object.xml
Can this be fixed so that the psib parameter only gives you a handle to a map that gives you objects you have permissions to see?
Thanks
Stephen
--
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, 2 months
[JBoss JIRA] Created: (JBAS-3824) Fix environment context for EJB2.1 and Servlets
by Thomas Diesler (JIRA)
Fix environment context for EJB2.1 and Servlets
-----------------------------------------------
Key: JBAS-3824
URL: http://jira.jboss.com/jira/browse/JBAS-3824
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Fix For: JBossAS-5.0.0.CR1
/home/tdiesler/svn/jbossws/trunk/src/test
[tdiesler@tdvaio test]$ ant -Dtest=jaxrpc/enventry test
tests-main:
[junit] Running org.jboss.test.ws.jaxrpc.enventry.EnvEntryEJBTestCase
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.982 sec
[junit] Test org.jboss.test.ws.jaxrpc.enventry.EnvEntryEJBTestCase FAILED
[junit] Running org.jboss.test.ws.jaxrpc.enventry.EnvEntryJSETestCase
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 3 sec
[junit] Test org.jboss.test.ws.jaxrpc.enventry.EnvEntryJSETestCase FAILED
--
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, 2 months
[JBoss JIRA] Created: (JBCACHE-784) "Random" TimeoutException occurs after CacheLoader get() returns
by James Hickey (JIRA)
"Random" TimeoutException occurs after CacheLoader get() returns
----------------------------------------------------------------
Key: JBCACHE-784
URL: http://jira.jboss.com/jira/browse/JBCACHE-784
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1 instances (pessimistic locking), no eviction policy
Reporter: James Hickey
Assigned To: Manik Surtani
We experience a strange issue which happens every so often whereby shortly after one of our replicated cache instances calls it's CacheLoader.get() to populate a particular FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the scenario/stack trace follows:
The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's get() method successfully returns (can see this as we have debugging in the cache loader). Subsequent calls are instantaneously successful and do not result in a further call to the cacheloader.
It looks to me like it could possibly be some kind of tx/locking/thread contention issue, as it happens more often than not where we have approx 10-20 threads which have all resulted in a call to the cache loader in a short space of time.
Any advice/opinion would be appreciated
Thanks
James
org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted@10e4fd3)
at org.jboss.cache.Node.acquire(Node.java:407)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
at org.jboss.cache.TreeCache.get(TreeCache.java:3453)
--
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, 2 months