January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-788) ConcurrentCloseStressTest fails

by Tim Fox (JIRA)

ConcurrentCloseStressTest fails ------------------------------- Key: JBMESSAGING-788 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-788 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta2 ConcurrentCloseStressTest fails with a NPE in ServerConnectionEndpoint::processTransaction because it cannot find a closed session. This is due to a bug in ClientTransaction::getDeliveriesForSession which would end up creating a new entry for the session id passed in the parameters every time. -- 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, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-312) StandaloneBootStrapper Messages

by Burr Sutter (JIRA)

StandaloneBootStrapper Messages ------------------------------- Key: JBESB-312 URL: http://jira.jboss.com/jira/browse/JBESB-312 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.0 Reporter: Burr Sutter Assigned To: Esteban Schifman Fix For: 4.0 When the application server is restarted out from under a live running listener (via the Standalonebootstrapper) it does appear to work once the app server is brought back to life. However, it produces a long stacktrace. Even after it redeploys the services (even though it shouldn't hav redeployed the servcies because their config file was untouched) it continues to complain and throw up errors/warnings until freshly restarted. [java] 19:15:14,465 WARN [Connection Monitor Thread][Connection] Connectio n failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(Cloc kDaemon.java:364) [java] at java.lang.Thread.run(Thread.java:595) [java] Caused by: java.io.IOException: ping timeout. [java] ... 3 more [java] 19:15:18,027 WARN [Connection Monitor Thread][Connection] Connectio n failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(Cloc kDaemon.java:364) [java] at java.lang.Thread.run(Thread.java:595) [java] Caused by: java.io.IOException: ping timeout. [java] ... 3 more [java] 19:15:18,027 WARN [Connection Monitor Thread][Connection] Connectio n failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(Cloc kDaemon.java:364) [java] at java.lang.Thread.run(Thread.java:595) [java] Caused by: java.io.IOException: ping timeout. [java] ... 3 more [java] 19:15:18,183 WARN [Connection Monitor Thread][Connection] Connectio n failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(Cloc kDaemon.java:364) [java] at java.lang.Thread.run(Thread.java:595) [java] Caused by: java.io.IOException: ping timeout. [java] ... 3 more [java] 19:15:18,308 WARN [Connection Monitor Thread][Connection] Connectio n failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(Cloc kDaemon.java:364) [java] at java.lang.Thread.run(Thread.java:595) [java] Caused by: java.io.IOException: ping timeout. [java] ... 3 more [java] 19:15:20,043 WARN [Connection Monitor Thread][Connection] Connectio n failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(Cloc -- 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, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-632) Package explorer view and Create package

by Michael Neale (JIRA)

Package explorer view and Create package ---------------------------------------- Key: JBRULES-632 URL: http://jira.jboss.com/jira/browse/JBRULES-632 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-921) Eviction eventually cleans up nodes that are cleared but not removed

by Brian Stansberry (JIRA)

Eviction eventually cleans up nodes that are cleared but not removed -------------------------------------------------------------------- Key: JBCACHE-921 URL: http://jira.jboss.com/jira/browse/JBCACHE-921 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Eviction does not remove nodes that have children, it only clears their data map. If such nodes are never accessed again, the eviction thread will never process them, and they will never be removed, leaving around several hundred bytes of litter per node. E.g. 1) create /a/1 2) create /a/1/xxx An LRU policy will try to evict /a/1 first, but the node will not be removed because /a/1/xxx still exists. Later /a/1/xxx will be evicted, but unless some event occurs that puts an entry for /a/1 back into the queue, it will never be evicted. One possible solution is to have CacheImpl._evict return a boolean that indicates if the node was actually removed. EvictionInterceptor could track that return value, and if false, add a new event to the region, perhaps with a new NodeEventType. Eviction policies could then revisit those nodes on the next run of the thread. -- 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, 5 months

1
5
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-57) Re-factor testsuite directory

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-57?page=all ] Brian Stansberry updated JBCLUSTER-57: -------------------------------------- Fix Version/s: Q2Y7 (was: Q4Y6) > Re-factor testsuite directory > ----------------------------- > > Key: JBCLUSTER-57 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-57 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Priority: Minor > Fix For: Q2Y7 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Current tests-cluutering target uses everything from tests/cluster/test. Now it has all of the clustering tests. But eventually we will need to refactor it into directories like sfsb, http, enetity, etc. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-40) Support for ejb3 SFSB passivation using JBossCache overflowing

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-40?page=all ] Brian Stansberry updated JBCLUSTER-40: -------------------------------------- Fix Version/s: Q1Y7 (was: Q4Y6) > Support for ejb3 SFSB passivation using JBossCache overflowing > -------------------------------------------------------------- > > Key: JBCLUSTER-40 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-40 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q1Y7 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently, SFSB has its own activation/passivation policy on top of JBossCache. When JBossCache supports its own activation/passivation policy, we should port it to ejb3. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-40) Support for ejb3 SFSB passivation using JBossCache overflowing

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-40?page=all ] Brian Stansberry reassigned JBCLUSTER-40: ----------------------------------------- Assignee: Brian Stansberry (was: Hany Mesha) > Support for ejb3 SFSB passivation using JBossCache overflowing > -------------------------------------------------------------- > > Key: JBCLUSTER-40 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-40 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q1Y7 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently, SFSB has its own activation/passivation policy on top of JBossCache. When JBossCache supports its own activation/passivation policy, we should port it to ejb3. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-14) http session failover using single shared DB with cache loader

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-14?page=all ] Brian Stansberry updated JBCLUSTER-14: -------------------------------------- Fix Version/s: Q2Y7 (was: Q3Y6) > http session failover using single shared DB with cache loader > -------------------------------------------------------------- > > Key: JBCLUSTER-14 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-14 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Priority: Minor > Fix For: Q2Y7 > > Original Estimate: 8 weeks > Remaining Estimate: 8 weeks > > To achieve http session failover, alternatively we can use a single shared DB with CacheLoader for multiple cache instances. All the session states will be persisted to the shared DB. When failing over, it will simply retrieve from the DB if it is not there yet. > This approach can scale very well. But it will be slower since every session setAttribute operation involves trip to DB. JBossCache already supports this semantics now. All we need is someone to verify it and benchmark 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

19 years, 5 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-14) http session failover using single shared DB with cache loader

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-14?page=all ] Brian Stansberry reassigned JBCLUSTER-14: ----------------------------------------- Assignee: Brian Stansberry (was: Ben Wang) > http session failover using single shared DB with cache loader > -------------------------------------------------------------- > > Key: JBCLUSTER-14 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-14 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Priority: Minor > Fix For: Q2Y7 > > Original Estimate: 8 weeks > Remaining Estimate: 8 weeks > > To achieve http session failover, alternatively we can use a single shared DB with CacheLoader for multiple cache instances. All the session states will be persisted to the shared DB. When failing over, it will simply retrieve from the DB if it is not there yet. > This approach can scale very well. But it will be slower since every session setAttribute operation involves trip to DB. JBossCache already supports this semantics now. All we need is someone to verify it and benchmark 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

19 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-8) Stateful session bean (SFSB) replication in EJB3

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-8?page=all ] Brian Stansberry updated JBCLUSTER-8: ------------------------------------- Fix Version/s: Q1Y7 (was: Q3Y6) Assignee: Brian Stansberry (was: Ben Wang) > Stateful session bean (SFSB) replication in EJB3 > ------------------------------------------------ > > Key: JBCLUSTER-8 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-8 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Priority: Critical > Fix For: Q1Y7 > > > Currently Bill has implemented SFSB in ejb3 using JBossCache. Need to track further integration issue(s). -- 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, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2007