jbosscache-issues March 2013

jbosscache-issues@lists.jboss.org

1 participants
5 discussions

[JBoss JIRA] (JBCACHE-1630) Cache fails to passivate on windows due to ':' in file url

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBCACHE-1630?page=com.atlassian.jira.plug... ] Bartosz Baranowski edited comment on JBCACHE-1630 at 3/5/13 7:36 AM: --------------------------------------------------------------------- Patch also updates trunk version to 3.2.12 since its not correct. It introduces static field + property to switch to new style, to avoid breaking backward compatibility. was (Author: baranowb): Patch also updates trunk version to 3.2.12 since its not correct. > Cache fails to passivate on windows due to ':' in file url > ---------------------------------------------------------- > > Key: JBCACHE-1630 > URL: https://issues.jboss.org/browse/JBCACHE-1630 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Manik Surtani > Attachments: JBCACHE-1630.patch > > > versions dont exists so: > Affected: 3.2.11.GA-- > Fix : 3.2.12 -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBCACHE-1630) Cache fails to passivate on windows due to ':' in file url

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBCACHE-1630?page=com.atlassian.jira.plug... ] Bartosz Baranowski updated JBCACHE-1630: ---------------------------------------- Attachment: JBCACHE-1630.patch Patch also updates trunk version to 3.2.12 since its not correct. > Cache fails to passivate on windows due to ':' in file url > ---------------------------------------------------------- > > Key: JBCACHE-1630 > URL: https://issues.jboss.org/browse/JBCACHE-1630 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bartosz Baranowski > Assignee: Manik Surtani > Attachments: JBCACHE-1630.patch > > > versions dont exists so: > Affected: 3.2.11.GA-- > Fix : 3.2.12 -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBCACHE-1630) Cache fails to passivate on windows due to ':' in file url

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBCACHE-1630: ------------------------------------------- Summary: Cache fails to passivate on windows due to ':' in file url Key: JBCACHE-1630 URL: https://issues.jboss.org/browse/JBCACHE-1630 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Bartosz Baranowski Assignee: Manik Surtani versions dont exists so: Affected: 3.2.11.GA-- Fix : 3.2.12 -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBCACHE-1267) Revert JBCACHE-1266 fix

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/JBCACHE-1267?page=com.atlassian.jira.plug... ] Brian Stansberry updated JBCACHE-1267: -------------------------------------- Assignee: (was: Brian Stansberry) Seems I forgot about it forever. > Revert JBCACHE-1266 fix > ----------------------- > > Key: JBCACHE-1267 > URL: https://issues.jboss.org/browse/JBCACHE-1267 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Priority: Minor > Fix For: 3.3.0.GA > > > The fix for JBCACHE-1266 is a workaround that should be reverted when JBCACHE-1265 is fixed. -- 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

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBCACHE-1472) Re-enable org.jboss.cache.integration.websession.BuddyReplicationFailoverTest

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/JBCACHE-1472?page=com.atlassian.jira.plug... ] Brian Stansberry updated JBCACHE-1472: -------------------------------------- Assignee: (was: Brian Stansberry) > Re-enable org.jboss.cache.integration.websession.BuddyReplicationFailoverTest > ----------------------------------------------------------------------------- > > Key: JBCACHE-1472 > URL: https://issues.jboss.org/browse/JBCACHE-1472 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Fix For: 3.3.0.GA > > > Test has been disabled because of this: > Mircea Markus wrote: > > One of them is the next one, on testInvalidateOnFailoverToBackup: > > > > This is the code I am talking about: > > InvalidationServlet invs = new InvalidationServlet(); > > MultipleActionServlet mas = new MultipleActionServlet(sas, invs); > > (....) > > req = new Request(mgr0, sessionId, mas); > > *1+2* req.execute(); (...) > > *3*BuddyReplicationAssertions.assertUnrelated(contextHostName, > > sessionId, mgr0.getCache()); > > > > And some explanation > > > > 1) manager0.invalidatesSession (i.e. cache0.remove) > > 2) manager0 tries to data gravitate session (i.e. cache0.get with > > forceDataGrav set to true). This is done last line in Request.execute(). > > 3) asserts that session is no longer present on cache0 > > > > Now, the assumption at 3 is not necessarily valid. With some funny > > threading and using ASYNC replication, you might have the remote > > removeNode command originated from cache0 to run *after* gravitateData > > originated at step2. I.e. RemoveNodeCommand being executed after > > GravitateDataCommand on cache*1* (buddy of cache0). > This scenario is a known issue -- the RemoveNodeCommand is unicast to the buddy while the GravitateDataCommand is multicast. JGroups does not impose ordering between unicast and multicast, so the order from the sender can be lost. > The "last line in Request.execute()" that causes the behavior mimics a portion of actual AS session replication code, a piece that is a general part of JBoss Web and outside of the control of the session replication logic. > This JIRA is to examine the test and determine what can be salvaged versus what needs to be isolated in a separate "known issue" test. -- 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

11 years, 1 month

1
0
0 / 0

← Newer
1
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues March 2013