[JBoss JIRA] Created: (EJBTHREE-984) Named queries containing sql reserved words survive deployment but fail at runtime.
by Thomas Skjlberg (JIRA)
Named queries containing sql reserved words survive deployment but fail at runtime.
------------------------------------------------------------------------------------
Key: EJBTHREE-984
URL: http://jira.jboss.com/jira/browse/EJBTHREE-984
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.0 GA
Environment: Windows, eclipse 3.1.2 and Jboss 4.2GA and the built-in database, EJB 3.0
Reporter: Thomas Skjlberg
Priority: Optional
Named queries in the entity beans are accepted at deployment however fail at runtime.
It looks like the reserved words just are removed from the consequent sql command used by JBoss, hence resulting in an unexpected token exception during parsing.
... A <= B ...
becomes
... <= B
Altering tables from entity beans that have fields with the sql reserved word START, END and TIME fail, probably due to the same reason. No other reserved words tried.
--
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, 11 months
[JBoss JIRA] Created: (JBAS-3848) jms message disappeared from db then exception is occured
by Ramil Israfilov (JIRA)
jms message disappeared from db then exception is occured
---------------------------------------------------------
Key: JBAS-3848
URL: http://jira.jboss.com/jira/browse/JBAS-3848
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS service
Affects Versions: JBossAS-4.0.5.GA
Environment: JBOSS 4.0.5.GA, JDK1.5.0_06, solarisx86, clustered on two nodes
Reporter: Ramil Israfilov
Assigned To: Adrian Brock
We running clustered jboss4.0.5 and JBOSS MQ is configured to run in clustered environment.
The node which was running Jboss MQ went down. JBOSS MQ successfully restarted on second node.But deliver of JMS message failed with error:
2006-11-13 11:47:59,130 ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] (cludev02) (WorkManager(3)-28:) Unexpected error delivering message SpyTextMessage {
Header {
jmsDestination : QUEUE.certione/ExecutorQueue
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 4
jmsMessageID : ID:13-116341486898510
jmsTimeStamp : 1163414868985
jmsCorrelationID: null
jmsReplyTo : null
jmsType : CertioneAsyncProcessingMessage
jmsRedelivered : false
jmsProperties : {TrackItemId=738, ExecutorName=certione/PreProcessingProcessRemote, TokenId=19666, AuditRecord=137}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:13
}
Body {
text :null
}
}
javax.ejb.EJBException: Failed to acquire the pool semaphore, strictTimeout=10000
at org.jboss.ejb3.StrictMaxPool.get(StrictMaxPool.java:106)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:245)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:268)
at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:138)
at $Proxy272.onMessage(Unknown Source)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:183)
at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:905)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
at org.jboss.mq.SpySession.run(SpySession.java:323)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:249)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:595)
And the most important is that JMS message disappeared after that from database !
--
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, 11 months
[JBoss JIRA] Created: (JBAS-3738) On Windows: timer.test.BasicTimerUnitTestCase fails
by Prabhat Jha (JIRA)
On Windows: timer.test.BasicTimerUnitTestCase fails
---------------------------------------------------
Key: JBAS-3738
URL: http://jira.jboss.com/jira/browse/JBAS-3738
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Environment: Windows 2003, Sun JDK1.4
Reporter: Prabhat Jha
Assigned To: Dimitris Andreadis
Fix For: JBossAS-4.0.5.GA
Test Class: org.jboss.test.timer.test.BasicTimerUnitTestCase
Test Name: testMDBTimer
Message property 'UNIQUE_ID' not set.
java.lang.NumberFormatException: Message property 'UNIQUE_ID' not set.
at org.jboss.mq.SpyMessage.getIntProperty(SpyMessage.java:581)
at org.jboss.test.timer.test.BasicTimerUnitTestCase.testMDBTimer(BasicTimerUnitTestCase.java:332)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
--
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, 11 months
[JBoss JIRA] Created: (JGRP-459) disable_initial_coord not working
by Graeme Ahokas (JIRA)
disable_initial_coord not working
----------------------------------
Key: JGRP-459
URL: http://jira.jboss.com/jira/browse/JGRP-459
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP1
Environment: mac os x, Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Reporter: Graeme Ahokas
Assigned To: Bela Ban
We've got the following scenario: three applications, App1, App2, and App3. We want App3 to be the coordinator when the apps first start, so there is no confusion about multiple groups / coordinators. So, we set App1 and App2's disable_initial_coord = true, and App3's disable_initial_coord=false.
Then we start App1, and it will wait. Then we start App2, and App1 / App2 will determine a coordinator, even though disable_initial_coord is set to true for both, and we have not started App3 yet! This seems to conflict with the documentation which states:
Note that - if a member is started as first member of a group - but its property is set to true, then it will loop until another member whose disable_initial_coord property is set to false, is started.
We need disable_initial_coord to work as documented.
--
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, 11 months