[JBoss JIRA] Created: (JBAS-3423) Fix org.jboss.test.cmp2.commerce.CompleteUnitTestCase in HEAD
by Anil Saldhana (JIRA)
Fix org.jboss.test.cmp2.commerce.CompleteUnitTestCase in HEAD
-------------------------------------------------------------
Key: JBAS-3423
URL: http://jira.jboss.com/jira/browse/JBAS-3423
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: CMP service
Reporter: Anil Saldhana
Assigned To: Alexey Loubyansky
Fix For: JBossAS-5.0.0.Beta
Could you please have a look at why the tests "testJBossQL, testEJBQL" are failing?
==========================================================================================
Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id)
junit.framework.AssertionFailedError: Expected: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t1_o1_customer, CUSTOMEREJB t2_o2_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t0_o1.customer=t1_o1_customer.id AND t3_o2.customer=t2_o2_customer.id) but got: SELECT t0_o1.ORDER_NUMBER FROM ORDER_DATA t0_o1, ORDER_DATA t3_o2, CUSTOMEREJB t2_o2_customer, CUSTOMEREJB t1_o1_customer WHERE (( NOT (t1_o1_customer.id=t2_o2_customer.id)) AND (t0_o1.CC_TYPE=t3_o2.CC_TYPE AND t0_o1.CC_FIRST_NAME=t3_o2.CC_FIRST_NAME AND t0_o1.CC_MI=t3_o2.CC_MI AND t0_o1.CC_LAST_NAME=t3_o2.CC_LAST_NAME AND t0_o1.CC_BILLING_ZIP=t3_o2.CC_BILLING_ZIP AND t0_o1.CC_CARD_NUMBER=t3_o2.CC_CARD_NUMBER) AND t3_o2.customer=t2_o2_customer.id AND t0_o1.customer=t1_o1_customer.id)
at org.jboss.test.cmp2.commerce.QueryTest.testJBossQL(QueryTest.java:173)
at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133)
at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102)
at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ws.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:39)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:168)
at org.jboss.ejb.plugins.SecurityAuthorizationInterceptor.invoke(SecurityAuthorizationInterceptor.java:105)
at org.jboss.ejb.plugins.JaasAuthenticationInterceptor.invoke(JaasAuthenticationInterceptor.java:146)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:646)
at org.jboss.ejb.Container.invoke(Container.java:974)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
=========================================================================================
--
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
18 years, 5 months
[JBoss JIRA] Created: (JBCACHE-923) Aquired node lock never released after transaction timeout
by Jacek Halat (JIRA)
Aquired node lock never released after transaction timeout
----------------------------------------------------------
Key: JBCACHE-923
URL: http://jira.jboss.com/jira/browse/JBCACHE-923
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Affects Versions: 1.4.0.SP1
Environment: Windows XP, Weblogic 9.1
Reporter: Jacek Halat
Assigned To: Ben Wang
Priority: Critical
Under weblogic 9.1 (and probably earlier version too, not tested) in some situations locks aquired on nodes are never released. Only way to release locks is stop and start again treecache.
On WebLogic the rollback after a tx timeout is handled in a separate thread (and all registered transaction synchronization handlers are invoked in separated thread! In treecache information about InvocationContext (GlobalTransaction, Transaction etc) is stored in ThreadLocal. In this situation SynchronizationHandler is scrubbing NOT correct invocationContext with information about currend rolled-back transaction, but new created empty invocationContext !!!! Informations from TransactionTable are correctly removed, because mapping of transactions is not stored in ThreadLocal variable.
This caused unexpected effects:
Information about GlobalTransaction is not cleared and when in main thread TransactionTimedOutException is catched and put/get operations without explicity created transaction are invoked, TreeCache is trying aquire RL/WL on node and caller is set to non-exist and cleared GlobalTransaction. Lock is aquired but not added to LockTable! (and not released).
>From now every access to locked node failed, because RL/WL can't be aquired in 10 secs. Only way to get system working is stop and start again TreeCache.
2007-01-04 10:13:42,092 DEBUG - calling aftercompletion for GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - Running rollback phase
2007-01-04 10:13:42,092 DEBUG - running rollback for GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - PessimisticLockInterceptor invoked for method rollback(GlobalTransaction:<192.168.141.1:2100>:1)
2007-01-04 10:13:42,092 DEBUG - called to rollback cache with GlobalTransaction=GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - _remove(GlobalTransaction:<192.168.141.1:2100>:1, "/NODEA/NODEB", systemProperty)
2007-01-04 10:13:42,092 DEBUG - _remove(GlobalTransaction:<192.168.141.1:2100>:1, "/NODEA/NODEB")
2007-01-04 10:13:42,092 DEBUG - removed child NODEB
2007-01-04 10:13:42,092 DEBUG - releasing lock for /NODEA/NODEB (<unlocked>)
2007-01-04 10:13:42,092 DEBUG - releasing lock for /NODEA (read owners=[GlobalTransaction:<192.168.141.1:2100>:1])
2007-01-04 10:13:42,092 DEBUG - removing local transaction Name=FooManager.foo,Xid=BEA1-00068143BD8A02E8BAA1(4771853),Status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 20 seconds
BEA1-00068143BD8A02E8BAA1],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=30,seconds left=20,activeThread=Thread[Timer-5,5,Pooled Threads],XAServerResourceInfo[dataSource]=(ServerResourceInfo[dataSource]=(state=rolledback,assigned=AdminServer),xar=dataSource,re-Registered = false),SCInfo[sample_domain+AdminServer]=(state=rolledback),properties=({weblogic.transaction.name=FooManager.foo}),local properties=({weblogic.jdbc.jta.dataSource=[ No XAConnection is attached to this TxInfo ]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=AdminServer+10.1.1.218:9002+sample_domain+admin+, XAResources={dataSource, WLStore_sample_domain__WLS_AdminServer},NonXAResources={})],CoordinatorURL=AdminServer+10.1.1.218:9002+sample_domain+admin+) and global transaction GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - bypassed locking as method rollback() doesn't require locking
2007-01-04 10:13:42,092 DEBUG - Suppressing invocation of method rollback(GlobalTransaction:<192.168.141.1:2100>:1) on cache.
2007-01-04 10:13:42,092 DEBUG - Attempting to release locks on current thread. Lock table is {}
2007-01-04 10:13:42,092 DEBUG - Finished local commit/rollback method for GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:13:42,092 DEBUG - Finished rollback phase
(...)
2007-01-04 10:14:12,302 DEBUG - Non-tx and non crud meth
2007-01-04 10:14:37,310 DEBUG - (192.168.141.1:2100) call on method [_get(/NODEC, NODE_VALUE, true)]
2007-01-04 10:14:37,310 DEBUG - PessimisticLockInterceptor invoked for method _get(/NODEC, NODE_VALUE, true)
2007-01-04 10:14:37,310 DEBUG - Attempting to lock node /NODEC for owner GlobalTransaction:<192.168.141.1:2100>:1
2007-01-04 10:14:37,310 DEBUG - acquiring RL: fqn=/NODEC, caller=GlobalTransaction:<192.168.141.1:2100>:1, lock=<unlocked>
2007-01-04 10:14:37,310 DEBUG - acquired RL: fqn=/NODEC, caller=GlobalTransaction:<192.168.141.1:2100>:1, lock=read owners=[GlobalTransaction:<192.168.141.1:2100>:1]
2007-01-04 10:14:37,310 ERROR - transaction entry not found for (gtx=GlobalTransaction:<192.168.141.1:2100>:1)
2007-01-04 10:14:37,310 DEBUG - Invoking method _get(/NODEC, NODE_VALUE, true) on cache.
2007-01-04 10:14:37,310 DEBUG - _get("/NODEC", NODE_VALUE, "true")
2007-01-04 10:14:37,310 DEBUG - Attempting to release locks on current thread. Lock table is {}
--
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
18 years, 5 months
[JBoss JIRA] Created: (JBAS-4152) Upgrade to hsql 1.8.0.7 causes org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2 to fail
by Vivek Lakshmanan (JIRA)
Upgrade to hsql 1.8.0.7 causes org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2 to fail
-------------------------------------------------------------------------------------------------------------------
Key: JBAS-4152
URL: http://jira.jboss.com/jira/browse/JBAS-4152
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-4.0.5.CR1
Environment: BEA JRockit 1.5.0_08 on Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Reporter: Vivek Lakshmanan
Assigned To: Scott M Stark
On upgrade of HSQLDB from 1.8.0.2 to 1.8.0.7 the following testcase seems to consistently fail:
org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase::testCMRmn2
Error: FKey cmr2_id is indexed
The test reports say:
junit.framework.AssertionFailedError: Error: FKey cmr2_id is indexed
at org.jboss.test.cmp2.idxandusersql.test.IdxAndUsersqlUnitTestCase.testCMRmn2(IdxAndUsersqlUnitTestCase.java:190)
at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133)
at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBean.java:102)
at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:44)
at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:173)
at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:77)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:169)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
The sourcefile for the test says:
/*
* Look for indices on the m:n mapping table
* This is for hsql a strange case, at indices are put there
* anyway, but it has been told that other databases don't do
* it by themselves, so we check if the creation succeeds.
*/
Would like to get an experts opinion on it
--
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
18 years, 5 months
[JBoss JIRA] Created: (JBAS-3976) Stateful Session Bean throws a Null Security Context exception with no login
by Anil Saldhana (JIRA)
Stateful Session Bean throws a Null Security Context exception with no login
----------------------------------------------------------------------------
Key: JBAS-3976
URL: http://jira.jboss.com/jira/browse/JBAS-3976
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1
Since the stateful session bean instance interceptor happens before the security interceptor (security exceptions need to invalidate the session), the call to set the principal on the enterprise context can fail when the bean was invoked with no login. Remember the getCallerPrincipal call on the context needs to always return a non-null principal.
If the setting of the principal on the context happens after the security checks have been made via the security interceptor, there is security domain settings reflected via the unauthenticated principal setting on the domain into the principal to be set on the context.
Of course the user can always specify the unauthenticated-principal tag in jboss-app.xml/jboss.xml DD but this should not be mandatory.
There is a need for a new interceptor after the security interceptor.
--
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
18 years, 5 months
[JBoss JIRA] Created: (JBAS-4130) Simple HelloWorld JSF 1.2 application does not work
by sedat ciftci (JIRA)
Simple HelloWorld JSF 1.2 application does not work
---------------------------------------------------
Key: JBAS-4130
URL: http://jira.jboss.com/jira/browse/JBAS-4130
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-5.0.0.Beta1
Environment: Windows XP, JSF application is created with Netbeans5.5 (+ Visual Web Pack)
Reporter: sedat ciftci
Assigned To: Dimitris Andreadis
I have faced with a problem while deploying my JSF 1.2 web application (sun impl) ( I build with Netbeans 5.5 Visual Web pack) to JBoss5 Beta. It works with Glassfish. In order to find the problem, I make a simple Hello world web application and try to deploy it to JBoss5Beta. However, I get the same exception.
The first exception that I overcome is related with web-facesconfig_1_2.xsd. JBoss says that it can not resolve this schema. I solve this problem by putting this file into the jboss.jar/schema.
The second exception that I cannot solve is although my projects managed-beans.xml file is well formed, JBoss throws such an exception:
org.jboss.deployers.spi.DeploymentException: The xml JBoss5Ex.war/WEB-INF/managed-beans.xml is not well formed!
at org.jboss.deployers.plugins.deployers.helpers.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:94)
at org.jboss.deployers.plugins.deployers.helpers.AbstractParsingDeployer.parse(AbstractParsingDeployer.java:173)
at org.jboss.deployers.plugins.deployers.helpers.AbstractParsingDeployer.createMetaData(AbstractParsingDeployer.java:114)
at org.jboss.deployers.plugins.deployers.helpers.AbstractParsingDeployer.createMetaData(AbstractParsingDeployer.java:88)
at org.jboss.deployers.plugins.deployers.kernel.BeanDeployer.deploy(BeanDeployer.java:59)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:366)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:246)
at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401)
at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340)
at org.jboss.Main.boot(Main.java:210)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:595)
Note that JBoss5Ex.war is my web application. What can be the problem? Any suggestions?
Here is the content of my managed-beans.xml file (starting after the #'s line):
######################################
<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<managed-bean>
<managed-bean-name>SessionBean1</managed-bean-name>
<managed-bean-class>jboss5ex.SessionBean1</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>Page1</managed-bean-name>
<managed-bean-class>jboss5ex.Page1</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>ApplicationBean1</managed-bean-name>
<managed-bean-class>jboss5ex.ApplicationBean1</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>RequestBean1</managed-bean-name>
<managed-bean-class>jboss5ex.RequestBean1</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</faces-config>
#################################################
Thanks,
Sedat
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBAS-3468) JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
by Francis Labaere (JIRA)
JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
-----------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-3468
URL: http://jira.jboss.com/jira/browse/JBAS-3468
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS service
Affects Versions: JBossAS-4.0.2 Final
Environment: Windows XP
Reporter: Francis Labaere
Assigned To: Adrian Brock
Priority: Minor
Fix For: JBossAS-4.0.5.GA
When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection is set (explicitely using setClientID or implicitely). The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap. When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one. When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken. Subsequent calls to the server will generate exceptions: User session is not valid.
On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive:
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.' This exception is being propogated to the client as a HTTPILResponse.
2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade@2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade@1343c2a)
On the Client side: following stacktrace is visible
13:17:57 [MessageListenerThread - MyTopic] WARN org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
mq.Connection should start the ping thread after the ClientID is known.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBREM-675) Problems with Servlet invoker
by Tom Elrod (JIRA)
Problems with Servlet invoker
-----------------------------
Key: JBREM-675
URL: http://jira.jboss.com/jira/browse/JBREM-675
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 1.4.6.GA, 2.0.0.GA (Boon)
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.2.0.Beta1 (Bluto)
Attachments: ServletServerInvoker.java
Several problems with servlet invoker:
1) There can't be two servlet invokers (it's necessary, for example, if you want to use them for JBoss Messagning and for EJBs - they require separate connectors) because ObjectName is hard-coded in ServletServerInvoker.java
2) Null returns from invokers are sent to client as empty 204 responses and custom marshallers have no change to process return value. This breaks JBoss Messaging which expects that EVERY message contains at least two bytes (version tag and format tag).
--
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
18 years, 6 months