February 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6443) Investigate session persistence broken in non-HA profile

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-6443: ----------------------------------- Summary: Investigate session persistence broken in non-HA profile Key: AS7-6443 URL: https://issues.jboss.org/browse/AS7-6443 Project: Application Server 7 Issue Type: Bug Components: Clustering Reporter: Radoslav Husar Assignee: Radoslav Husar https://github.com/jbossas/jboss-as/pull/3978 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6443) Investigate session persistence broken in non-HA profile

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/AS7-6443?page=com.atlassian.jira.plugin.s... ] Radoslav Husar updated AS7-6443: -------------------------------- Fix Version/s: 7.2.0.Alpha1 > Investigate session persistence broken in non-HA profile > -------------------------------------------------------- > > Key: AS7-6443 > URL: https://issues.jboss.org/browse/AS7-6443 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 7.2.0.Alpha1 > > > https://github.com/jbossas/jboss-as/pull/3978 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6436) ServerSetupTask.tearDown methods should be called in the reverse order

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/AS7-6436?page=com.atlassian.jira.plugin.s... ] Josef Cacek closed AS7-6436. ---------------------------- Verified. > ServerSetupTask.tearDown methods should be called in the reverse order > ---------------------------------------------------------------------- > > Key: AS7-6436 > URL: https://issues.jboss.org/browse/AS7-6436 > Project: Application Server 7 > Issue Type: Bug > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Labels: arquillian > Fix For: 7.2.0.Alpha1 > > > The ServerSetupObserver should call the {{tearDown()}} methods in the reverse order. Otherwise it breaks setup/service dependencies. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1574. ---------------------------- Resolution: Done Pull requests applied > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 3.2.7, 3.3 > > > Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). > New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-3694) Allow management client to associate metadata with DeploymentUnit

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-3694?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-3694: ------------------------------------- BTW, happy birthday to this issue ;-) > Allow management client to associate metadata with DeploymentUnit > ----------------------------------------------------------------- > > Key: AS7-3694 > URL: https://issues.jboss.org/browse/AS7-3694 > Project: Application Server 7 > Issue Type: Feature Request > Components: OSGi, Server > Reporter: Thomas Diesler > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.2.0.CR1 > > > Currently there is no way to pass some metadata through the deployment API such that they could show up with the DU. > As a client I'd like to say autostart=false and in my DUP I'd like to pick that up and not start a deployment (i.e. a bundle) automatically > Generally it should be possible for the client to set some properties for the deployment in a generic way such that they get associated with the DeploymentUnit > For an OSGi deployment it would be necessary to be able to define that start behaviour and the start level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-3694) Allow management client to associate metadata with DeploymentUnit

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-3694?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned AS7-3694: ----------------------------------- Assignee: Brian Stansberry (was: Thomas Diesler) Brian, could you please provide a pointer to how this needs to get changed to use "subsystem typing"? cheers > Allow management client to associate metadata with DeploymentUnit > ----------------------------------------------------------------- > > Key: AS7-3694 > URL: https://issues.jboss.org/browse/AS7-3694 > Project: Application Server 7 > Issue Type: Feature Request > Components: OSGi, Server > Reporter: Thomas Diesler > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.2.0.CR1 > > > Currently there is no way to pass some metadata through the deployment API such that they could show up with the DU. > As a client I'd like to say autostart=false and in my DUP I'd like to pick that up and not start a deployment (i.e. a bundle) automatically > Generally it should be possible for the client to set some properties for the deployment in a generic way such that they get associated with the DeploymentUnit > For an OSGi deployment it would be necessary to be able to define that start behaviour and the start level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-780) UNICAST: regular message not delivered (in some cases) until new message arrives

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-780?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-780: -------------------------- Description: When we have the following situation, message B3 will not get delivered at A: - A and B - B sends 3 unicast messages: B1 (regular), B2 (OOB) and B3 (regular); B2 is dropped - A receives B1, B3, B2 - A delivers B1 - B3 has to wait until B2 is received, so the thread returns - B2 is received, but since it is OOB, after pushing the message up the stack, the thread terminates ! ==> B3 will not get delivered until B4 is received ! For NAKACK, this is not critical as stability messages will fix the 'last message lost problem'. But, it would be nice to have the same solution to this problem also for NAKACK... was: When we have the following situation, message B3 will not get delivered at A: - A and B - B sends 3 unicast messages: B1 (regular), B2 (OOB) and B3 (regular) - A receives B1, B3, B2 - A delivers B1 - B3 has to wait until B2 is received, so the thread returns - B2 is received, but since it is OOB, after pushing the message up the stack, the thread terminates ! ==> B3 will not get delivered until B4 is received ! For NAKACK, this is not critical as stability messages will fix the 'last message lost problem'. But, it would be nice to have the same solution to this problem also for NAKACK... > UNICAST: regular message not delivered (in some cases) until new message arrives > -------------------------------------------------------------------------------- > > Key: JGRP-780 > URL: https://issues.jboss.org/browse/JGRP-780 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 2.6.3, 2.7 > > > When we have the following situation, message B3 will not get delivered at A: > - A and B > - B sends 3 unicast messages: B1 (regular), B2 (OOB) and B3 (regular); B2 is dropped > - A receives B1, B3, B2 > - A delivers B1 > - B3 has to wait until B2 is received, so the thread returns > - B2 is received, but since it is OOB, after pushing the message up the stack, the thread terminates ! > ==> B3 will not get delivered until B4 is received ! > For NAKACK, this is not critical as stability messages will fix the 'last message lost problem'. But, it would be nice to have the same solution to this problem also for NAKACK... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1579) NAKACK2 / UNICAST2: last message sent to self may not get delivered

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1579?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1579. ---------------------------- Resolution: Rejected This is not a bug, as a message to self will *never* be discarded ! > NAKACK2 / UNICAST2: last message sent to self may not get delivered > ------------------------------------------------------------------- > > Key: JGRP-1579 > URL: https://issues.jboss.org/browse/JGRP-1579 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2.7, 3.3 > > > When A sends a message M that's received by A (M is either a multicast, or a unicast to A), and the message is dropped below NAKACK2 / UNICAST2, then A might *receive* M, but not *deliver* it if M is the last message sent. > Scenario (for NAKACK2, but similar to UNICAST2): > - A's table is: HD=9, HR=9 > - A sends M10 > - NAKACK2 adds M10: HD=9, HR=10 (highest-delivered is still 9, as we haven't removed M10 yet) > - The transport drops M10 > - A sends no further messages > - STABLE will make sure that A's HR is 10, but since no message was received, we won't *remove* any messages from A's table ! > --> The result is that although A *received* M10, it won't *deliver* M10 (until another message is received) ! > SOLUTION: > - Maybe we can use the retransmit task to see if there are any unremoved messages in a table and - if so - remove them and pass them up the stack to the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1579) NAKACK2 / UNICAST2: last message sent to self may not get delivered

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1579?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1579: -------------------------------- Actually, on second thought, this is not an issue, as *a message from A will always be received by A !* The problem occurred because we placed DISCARD just below NAKACK2; however, this is *not* the place where messages are dropped (or else this would constitute a bug !). Messages are dropped by the network, so we need to change the test OOBTest: move DISCARD down the stack, just above TP, and set up="0.5" instead of down="0.5". > NAKACK2 / UNICAST2: last message sent to self may not get delivered > ------------------------------------------------------------------- > > Key: JGRP-1579 > URL: https://issues.jboss.org/browse/JGRP-1579 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2.7, 3.3 > > > When A sends a message M that's received by A (M is either a multicast, or a unicast to A), and the message is dropped below NAKACK2 / UNICAST2, then A might *receive* M, but not *deliver* it if M is the last message sent. > Scenario (for NAKACK2, but similar to UNICAST2): > - A's table is: HD=9, HR=9 > - A sends M10 > - NAKACK2 adds M10: HD=9, HR=10 (highest-delivered is still 9, as we haven't removed M10 yet) > - The transport drops M10 > - A sends no further messages > - STABLE will make sure that A's HR is 10, but since no message was received, we won't *remove* any messages from A's table ! > --> The result is that although A *received* M10, it won't *deliver* M10 (until another message is received) ! > SOLUTION: > - Maybe we can use the retransmit task to see if there are any unremoved messages in a table and - if so - remove them and pass them up the stack to the application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-155) TP.loopback should always be used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-155?page=com.atlassian.jira.plugin.s... ] Bela Ban commented on JGRP-155: ------------------------------- The reason for the perf degradation is probably that we loop back messages *individually*, e.g. if A multicasts 1000 messages, TP.loopback=true will use 1 thread / message. SOLUTION: we should move the loopback handling after the bundling code, so that looped-backed messages are bundled (batched) as well. This way, we'll use fewer threads to handled looped backed messages. > TP.loopback should always be used > --------------------------------- > > Key: JGRP-155 > URL: https://issues.jboss.org/browse/JGRP-155 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.8, 2.2.9 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.x > > > Investigate the 3 potential problem areas below: > - Memory leak caused by FC when credits are received too quickly > - Deadlocks caused by same threads calling themselves (e.g. VIEW_OK ack msgs) > - Preemption doesn't work: Scheduler is meaningless here -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 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 February 2013