January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Resolved: (JBFORUMS-78) Stop Topic Watch

by Ryszard Kozmik (JIRA)

[ http://jira.jboss.com/jira/browse/JBFORUMS-78?page=all ] Ryszard Kozmik resolved JBFORUMS-78. ------------------------------------ Resolution: Done > Stop Topic Watch > ---------------- > > Key: JBFORUMS-78 > URL: http://jira.jboss.com/jira/browse/JBFORUMS-78 > Project: JBoss Forums > Issue Type: Sub-task > Affects Versions: 1.0.0 Beta > Reporter: Sohil Shah > Assigned To: Ryszard Kozmik > Fix For: 1.0.0 Beta > > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBFORUMS-77) Activate Topic Watch

by Ryszard Kozmik (JIRA)

[ http://jira.jboss.com/jira/browse/JBFORUMS-77?page=all ] Ryszard Kozmik resolved JBFORUMS-77. ------------------------------------ Resolution: Done > Activate Topic Watch > -------------------- > > Key: JBFORUMS-77 > URL: http://jira.jboss.com/jira/browse/JBFORUMS-77 > Project: JBoss Forums > Issue Type: Sub-task > Affects Versions: 1.0.0 Beta > Reporter: Sohil Shah > Assigned To: Ryszard Kozmik > Fix For: 1.0.0 Beta > > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-843) Data versions do not replicate properly alongside data

by Manik Surtani (JIRA)

Data versions do not replicate properly alongside data ------------------------------------------------------ Key: JBCACHE-843 URL: http://jira.jboss.com/jira/browse/JBCACHE-843 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 1.4.0.SP1 Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Critical Fix For: 1.4.1.GA, 2.0.0.GA In some cases, data versions are not replicated at all while in others, data versions are replicated but updating them causes problems. See org.jboss.cache.options.ExplicitVersionsReplTest in the "tests/functional" directory of Branch_JBossCache_1_4_0. -- 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, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAOP-329) Parameter annotations do not get copied across

by Kabir Khan (JIRA)

Parameter annotations do not get copied across ---------------------------------------------- Key: JBAOP-329 URL: http://jira.jboss.com/jira/browse/JBAOP-329 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha2 Reporter: Kabir Khan Assigned To: Kabir Khan Modify MethodExecutionTransformer.moveAnnotations() and use the jbaop316annotationsinwrapperonly test -- 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, 3 months

1
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-935) Data gravitation throws ArrayIndexOutOfBoundException with FLUSH based stack

by Vladimir Blagojevic (JIRA)

Data gravitation throws ArrayIndexOutOfBoundException with FLUSH based stack ---------------------------------------------------------------------------- Key: JBCACHE-935 URL: http://jira.jboss.com/jira/browse/JBCACHE-935 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 2.0.0.ALPHA2 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic DataGravitatorInterceptor was not aware that it can receive block/unblock events (originating from FLUSH) which led to throwing of ArrayIndexOutOfBoundException. Discovered during implementation of JBCACHE-840. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-714) Make sure all dependent instances of the failed connection (ConnectionFailureListener included) are propery garbage collected after failover

by Ovidiu Feodorov (JIRA)

Make sure all dependent instances of the failed connection (ConnectionFailureListener included) are propery garbage collected after failover -------------------------------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-714 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-714 Project: JBoss Messaging Issue Type: Sub-task Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 1.2.0.Beta2 -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Commented: (JBCACHE-629) SELECT FOR UPDATE semantics

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-629?page=comments#action_12350456 ] Manik Surtani commented on JBCACHE-629: --------------------------------------- Fixed in CVS HEAD, will be in BETA1. See o.j.c.options.ForceWriteLockTest for usage details. > SELECT FOR UPDATE semantics > --------------------------- > > Key: JBCACHE-629 > URL: http://jira.jboss.com/jira/browse/JBCACHE-629 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Manik Surtani > Fix For: 2.0.0.GA, 2.0.0.BETA1 > > > An API with semantics similar to a database SELECT FOR UPDATE would be useful -- e.g. getForUpdate(...) which acts like a get, but acquires a WL instead of a RL. > Example situation: > IsolationLevel is READ_COMMITTED > - Two threads A and B. > 1. Thread A starts a new Transaction. > 2. Thread A calls get(Fqn for x, key for x) > 3. Thread A modifies Object x (e.g x.setFoo("bar")). > 4. Thread B calls get(Fqn for x, key for Object x) > 5. Thread B calls x.getFoo() > 6. Thread A calls put(Fqn for x, key for x, x); > 7. Thread A rolls back the Transaction. > Problem is in Step 5 Thread B sees uncommitted data, because the WL on the cache node is not acquired until Step 6. Only way to control this is for Thread A to synchronize on x and write x in such a way that access to all properties like Foo are synchronized. > With getForUpdate, A would acquire the WL in step 1, thus blocking B from reading until the A's TX commits. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-629) SELECT FOR UPDATE semantics

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-629?page=all ] Manik Surtani closed JBCACHE-629. --------------------------------- Resolution: Done > SELECT FOR UPDATE semantics > --------------------------- > > Key: JBCACHE-629 > URL: http://jira.jboss.com/jira/browse/JBCACHE-629 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Manik Surtani > Fix For: 2.0.0.BETA1, 2.0.0.GA > > > An API with semantics similar to a database SELECT FOR UPDATE would be useful -- e.g. getForUpdate(...) which acts like a get, but acquires a WL instead of a RL. > Example situation: > IsolationLevel is READ_COMMITTED > - Two threads A and B. > 1. Thread A starts a new Transaction. > 2. Thread A calls get(Fqn for x, key for x) > 3. Thread A modifies Object x (e.g x.setFoo("bar")). > 4. Thread B calls get(Fqn for x, key for Object x) > 5. Thread B calls x.getFoo() > 6. Thread A calls put(Fqn for x, key for x, x); > 7. Thread A rolls back the Transaction. > Problem is in Step 5 Thread B sees uncommitted data, because the WL on the cache node is not acquired until Step 6. Only way to control this is for Thread A to synchronize on x and write x in such a way that access to all properties like Foo are synchronized. > With getForUpdate, A would acquire the WL in step 1, thus blocking B from reading until the A's TX commits. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-359) Add serialVersionUID to subclasses of Swing types

by Brian Stansberry (JIRA)

Add serialVersionUID to subclasses of Swing types ------------------------------------------------- Key: JGRP-359 URL: http://jira.jboss.com/jira/browse/JGRP-359 Project: JGroups Issue Type: Sub-task Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.5 In the demos package there are number of classes that descend from Swing types and thus inherit Serializable. None of these are meant to be serialized, but we should add serialVersionUIDs just to prevent spurious failures on serialization compatibility tests. -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-402) Simple Flow Control (SFC)

by Bela Ban (JIRA)

Simple Flow Control (SFC) ------------------------- Key: JGRP-402 URL: http://jira.jboss.com/jira/browse/JGRP-402 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 SFC is a simple flow control protocol for group (= multipoint) messages. Every sender has max_credits bytes for sending multicast messages to the group. Every multicast message (we don't consider unicast messages) decrements max_credits by its size. When max_credits falls below 0, the sender asks all receivers for new credits and blocks until *all* credits have been received from all members. When the receiver receives a credit request, it checks whether it has received max_credits bytes from the requester since the last credit request. If yes, it sends new credits to the requester and resets the max_credits for the requester. Else, it takes a note of the credit request from P and - when max_credits bytes have finally been received from P - it sends the credits to P and resets max_credits for P. The maximum amount of memory for received messages is therefore <number of senders> * max_credits. The relationship with STABLE is as follows: when a member Q is slow, it will prevent STABLE from collecting messages above the ones seen by Q (everybody else has seen more messages). However, because Q will *not* send credits back to the senders until it has processed all messages worth max_credits bytes, the senders will block. This in turn allows STABLE to progress and eventually garbage collect most messages from all senders. Therefore, SFC and STABLE complement each other, with SFC blocking senders so that STABLE can catch up. See doc/design/SimpleFlowControl.txt for details -- 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, 3 months

1
1
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