September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-558) Possible performance degradation relative to JBossMQ when using contested queues and selectors

by Ovidiu Feodorov (JIRA)

Possible performance degradation relative to JBossMQ when using contested queues and selectors ---------------------------------------------------------------------------------------------- Key: JBMESSAGING-558 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-558 Project: JBoss Messaging Issue Type: Bug Components: JMS Facade Affects Versions: 1.0.1.CR5, 1.0.1.CR4 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta1 Problem described on the forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91326 -- 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

4
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-548) Remote tests occasionaly fail with "Cannot find generator for serverid:server.0"

by Ovidiu Feodorov (JIRA)

Remote tests occasionaly fail with "Cannot find generator for serverid:server.0" -------------------------------------------------------------------------------- Key: JBMESSAGING-548 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.CR4 Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 1.0.1.CR5 Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance. -- 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

3
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-446) Start the QA process in concert with QA team

by Ovidiu Feodorov (JIRA)

Start the QA process in concert with QA team -------------------------------------------- Key: JBMESSAGING-446 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-446 Project: JBoss Messaging Issue Type: Task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.CR1 -- 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

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-454) InVM callbackserver

by Tim Fox (JIRA)

InVM callbackserver ------------------- Key: JBMESSAGING-454 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-454 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.0.1.CR3 Reporter: Tim Fox Fix For: 1.0.2 When running with both client and server invm and using the socket transport, a callbackserver is opened on the client and creates several sockets to listen for incoming requests. This uses up system resources (threads and sockets) which are never used for the invm case. -- 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

4
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-494) Add smoke test using ConnectionFactory

by Tim Fox (JIRA)

Add smoke test using ConnectionFactory -------------------------------------- Key: JBMESSAGING-494 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-494 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Fix For: 1.0.1.CR4 Need to add a smoke test that uses /ConnectionFactory as opposed to /JmsXA. This is because there was a classloader bug that only manifests when sending a message from an ejb to a topic using /Connectionfactory. Really, the smoke tests should be refactored to have a more appropriate use of connection factories. -- 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

4
3
0 / 0

[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

18 years, 5 months

4
4
0 / 0

[JBoss JIRA] Created: (JBRULES-453) ruleflow

by Mark Proctor (JIRA)

ruleflow -------- Key: JBRULES-453 URL: http://jira.jboss.com/jira/browse/JBRULES-453 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Leaps, Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 -- 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

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-449) Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory

by Juergen none (JIRA)

Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory ------------------------------------------------------------------------------------------------------------------- Key: JBRULES-449 URL: http://jira.jboss.com/jira/browse/JBRULES-449 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.4 Environment: jdk 1.4.2_10 Reporter: Juergen none Assigned To: Mark Proctor A rather complicated, intertwined set of rules leads to a logically asserted fact, that remains in working memory, even after its justifiers have been retracted. Sadly I have no unit-test, but I can outline the rules and execution sequence as reported by a listener (a ... assert, al ... assert logical, r ... retract) Its a buggy (R5 twice) implementation of a accumulating set of rules I posted in the user list some time ago. FFF(A), FFF(B) are of same class but not equal, @... is systemHashCode, so different instances, but possible equal (as mentioned) classes without @ have only one instance in working memory a XXX R0: XXX -> al DDD a AAA (external assert) Sequence of rules fired R1: AAA -> al GGG R2: DDD, GGG -> al CCC R3: GGG -> al EEE R4: EEE, DDD, CCC -> a BBB@15737ca, al FFF@b2d75c(A) (BBB@15737ca contributes to hash/equals of FFF@b2d75c) R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF@b274de(B) R5 again (modify triggered): EEE, DDD, CCC -> a BBB@16d8ba (but equals(BBB@15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF@2aefe3(A) (equals FFF@b2d75c, backing its logical dependency) (BBB@16d8ba contributes to Hash/equals)) --- r AAA (external retract) -> (according to listener): r AAA r GGG r EEE r CCC breakpoint, screenshot --> justifier list is invalid, contains retracted handles PoolCondition would be DDD, the only valid handle in the (EEE, DDD, CCC) tuple r XXX (retract of XXX has no consequence, just the last handle, still valid in the screenshot, becomes invalid too) -> r XXX r DDD workingMemory.getObjects() lists FFF@b2d75c(A) and FFF@b274de(B) for Rulebase-properties: - RuleBaseConfiguration.PROPERTY_ASSERT_BEHAVIOR -> RuleBaseConfiguration.WM_BEHAVIOR_IDENTITY - empty Major lead could be that after commenting out "mod CCC", FFF(A) is retracted (+ R5 not fired a second time) + problem with changed hashcode of CCC ? + problem with second instances of BBB and FFF(A) being asserted + FFF(B) being assert normally, not logically -- 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

4
12
0 / 0

[JBoss JIRA] Created: (JBPM-708) Version control of the process definition

by Aravind Kumar (JIRA)

Version control of the process definition ----------------------------------------- Key: JBPM-708 URL: http://jira.jboss.com/jira/browse/JBPM-708 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1.1 Reporter: Aravind Kumar Assigned To: Tom Baeyens When working with jBPM in developement environment, there is no control over the version of the process-definition. Each time the server is restarted, a new version is deployed. The work around that I did: <boolean name="update-definition" value="false"/> this tag is included in the jbpm.cfg.xml & a check at JbpmContext.java: public void deployProcessDefinition(ProcessDefinition processDefinition) { if(JbpmConfiguration.Configs.getBoolean("update-definition")) { getGraphSession().deployProcessDefinition(processDefinition); } } This works fine for a single process defifnition. In case, there are multiple process definitions and some needs to be updates and some need not be. -- 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

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-375) "?" doesn't seem to be recognized in the excel spreadsheet.

by wen Lin (JIRA)

"?" doesn't seem to be recognized in the excel spreadsheet. ------------------------------------------------------------- Key: JBRULES-375 URL: http://jira.jboss.com/jira/browse/JBRULES-375 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Decision tables Affects Versions: 3.0.1 Environment: window xp, eclipses-3.1.2 Reporter: wen Lin Assigned To: Mark Proctor In the action cell, I have int score = (i.getMyScore()< $param)? i.getMyScore(): $param; c.setAdjustScore(score); c.setFlag(false); modify( c ); and got the following errors: [mTokens]: line 25:39 state 0 (decisionfiltered=16) no viable alt line 25:39; char='?' [mTokens]: line 37:39 state 0 (decisionfiltered=16) no viable alt line 37:39; char='?' [mTokens]: line 49:39 state 0 (decisionfiltered=16) no viable alt line 49:39; char='?' [mTokens]: line 61:39 state 0 (decisionfiltered=16) no viable alt line 61:39; char='?' [mTokens]: line 73:39 state 0 (decisionfiltered=16) no viable alt line 73:39; char='?' [mTokens]: line 85:39 state 0 (decisionfiltered=16) no viable alt line 85:39; char='?' [mTokens]: line 97:39 state 0 (decisionfiltered=16) no viable alt line 97:39; char='?' Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token ------------------------------------------------------------------ but the problem disappears while I use the following instead: c.setAdjustScore(Math.min(i.getMyScore (), $param)); --------------------------------------------------------------------------------------- It seems to me that either "?" is not recognized or "(a>b)? a:b" doesn't work ... -- 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

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006