May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7186) SuspectExceptions during data gravitation lead to DataGravitationCleanup command not executing

by Brian Stansberry (JIRA)

SuspectExceptions during data gravitation lead to DataGravitationCleanup command not executing ---------------------------------------------------------------------------------------------- Key: JBAS-7186 URL: https://jira.jboss.org/jira/browse/JBAS-7186 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.1.0.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 JBC is different from JBC 1.4 in how it handles suspected nodes during data gravitation. JBC would ignore them; w/ JBC 3 they propagate. These can happen easily with a cluster under load and a node failing. LB detects failure before view changes, node that has failing node as it backup starts gravitating, replication of the gravitated data to the (failed) backup throws a SuspectException. The clustering integration needs to handle this better. Right now gravitation attempts are wrapped in txs, so the SuspectException fails the tx commit. That's pretty non-recoverable unless we catch the commit failure and retry. A possibility is to not wrap the gravitation in a tx (not really needed except for FIELD) and use JBossCacheWrapper's get() retry logic to redo the gravitation. We already catch the exception and allow the request to continue if the data was actually retrieved. Actually, that only works because we wrap w/ the tx; JBC wouldn't return from the gravitation read without the tx causing the replication write to wait for tx commit. Hmm... Problem this causes now is 1) gravitated data doesn't replicate to buddy until a request changes it and causes a normal write 2) DataGravitationCleanupCommand is not issued, so stale data is left in the cache. Some of the changes made for JBCACHE-1530 reduce the likelihood of that stale data being used; it's only used if a request fails over to the node where it's stored, leading to gravitation from (stale) local backup tree. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7296) Fix clustering related findbugs issues

by Brian Stansberry (JIRA)

Fix clustering related findbugs issues -------------------------------------- Key: JBAS-7296 URL: https://jira.jboss.org/jira/browse/JBAS-7296 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Review findbugs reports (see parent task), deal with issues in: 1) AS cluster module 2) JBCLUSTER project libraries 3) JBC 4) JGroups (notify JGroups team) 5) Cluster stuff in tomcat module 6) Cluster stuff in profile service 7) ServiceBindingManager A quick scan didn't show a whole lot, so this shouldn't be too bad. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-7583) Move ServiceBindingManager to deploy

by Brian Stansberry (JIRA)

Move ServiceBindingManager to deploy ------------------------------------ Key: JBAS-7583 URL: https://jira.jboss.org/jira/browse/JBAS-7583 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M2 Once JBAS-7580 is completed, all services that open sockets will be in deploy, so ServiceBindingManager can go there as well. Services like JBM that count on SBM setting system properties will need to have a dependency added since it's now possible SBM would start after they do. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-7580) Move RemoteNamingBean to deploy

by Brian Stansberry (JIRA)

Move RemoteNamingBean to deploy ------------------------------- Key: JBAS-7580 URL: https://jira.jboss.org/jira/browse/JBAS-7580 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Naming Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M2 RemoteNamingBean is currently in deployers. Move it to deploy. Bean Validation's JndiBinder is using JNDI in deployers, but it only needs LocalNamingBean. Once LocalNamingBean is deployed, any new InitialContext() call inside the AS will find the local server, so that should be sufficient; nothing in deployers should need RemoteNamingBean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-3753) HAParititonImpl implements org.jgroups.ChannelListener

by Brian Stansberry (JIRA)

HAParititonImpl implements org.jgroups.ChannelListener ------------------------------------------------------ Key: JBAS-3753 URL: http://jira.jboss.com/jira/browse/JBAS-3753 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.4.GA, JBossAS-3.2.8.SP1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 Currently if a JChannel is shunned and disconnects, higher level services are unaware of this and can't take any remedial action. We need to do something like implement ChannelListener so an HAPartition is aware when the events on the underlying channel occur. Then devise a scheme to propagate some of the events to user code. Preferably this will follow as much as possible the existing notification scheme; i.e. pass a new view to HAMembershipListener impls that doesn't include the current node. -- 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, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-7198) Replicate full session content after failover

by Brian Stansberry (JIRA)

Replicate full session content after failover --------------------------------------------- Key: JBAS-7198 URL: https://jira.jboss.org/jira/browse/JBAS-7198 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 Upstream version of JBPAPP-2529. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (GPD-393) Action field name conflicts with jpdl schema make GPD unable to display the action config for a node

by Justin Hayes (JIRA)

Action field name conflicts with jpdl schema make GPD unable to display the action config for a node ---------------------------------------------------------------------------------------------------- Key: GPD-393 URL: https://jira.jboss.org/browse/GPD-393 Project: jBPM GPD Issue Type: Bug Affects Versions: jBPM jPDL Designer 3.1.7 Environment: Windows 7, Eclipse 3.5.2, JBoss Tools 3.1 Reporter: Justin Hayes Assignee: Koen Aers Priority: Minor I have an action with a field called script. When I add this action to a node I can set the value of the field properly. Then if I close the process definition file and later reopen it and go to edit this action configuration GPD doesn't show that the field has already been configured, even though the source XML still contains the child element for the field in the <action> element. I believe this is because "script" is used elsewhere in the jpdl schema and GPD gets confused with it. The problem also exists when I use an action with the name "variable". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (SECURITY-476) Allow return of user name without realm part for legacy applications

by Matthias Kopczynski (JIRA)

Allow return of user name without realm part for legacy applications -------------------------------------------------------------------- Key: SECURITY-476 URL: https://jira.jboss.org/jira/browse/SECURITY-476 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Patch Security Level: Public (Everyone can see) Components: Negotiation Reporter: Matthias Kopczynski Assignee: Darran Lofthouse Attachments: cutOffDomainPatch.patch We have a legacy application which already uses authentication but cannot handle the realm part of the principal name. To enable single sign on we have made the changes in provided patch which allows to configure the module-option cutOffDomain for SPNEGOLoginModule. If the username ends with the realm name configured in this option the realm name is removed from the user name. This way the application gets the simpler name in the HttpServletRequest. Principals not ending with this realm are left untouched. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBNAME-14) Add support for remote NamingListeners

by Scott M Stark (JIRA)

Add support for remote NamingListeners -------------------------------------- Key: JBNAME-14 URL: https://jira.jboss.org/jira/browse/JBNAME-14 Project: JBoss Naming Issue Type: Feature Request Affects Versions: 5.0.0.GA Reporter: Scott M Stark Fix For: 5.1.0.Beta1 The current EventContext support is only designed for use with NamingListeners that are in the same jvm as the naming server. We need to expand this to support remote naming clients. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2516) Ruleflow Gateways(Splits) not working with Stateless Sessions

by Chris DeLashmutt (JIRA)

Ruleflow Gateways(Splits) not working with Stateless Sessions ------------------------------------------------------------- Key: JBRULES-2516 URL: https://jira.jboss.org/browse/JBRULES-2516 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (flow) Affects Versions: FUTURE Reporter: Chris DeLashmutt Assignee: Mark Proctor In 5.1.0.M1 and prior, you could have a ruleflow with a gateway(split) in it and it would work properly. This no longer works in trunk. I have tested this against revision 32993, but the problemwas probably introduced sooner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
8
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 May 2010