January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-902) Add explict serialVersionUID to all exception classes and serializable classes

by Elias Ross (JIRA)

Add explict serialVersionUID to all exception classes and serializable classes ------------------------------------------------------------------------------ Key: JBCACHE-902 URL: http://jira.jboss.com/jira/browse/JBCACHE-902 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani Although it's fairly tedious, it's not a bad idea to add a serialVersionUID to all exception and serializable classes. This will prevent accidental regressions such as JBAS-3772. It may be worth closesly examining the format of many serializable classes. -- 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: (JBCACHE-911) Remove or refactor NodeFactory

by Elias Ross (JIRA)

Remove or refactor NodeFactory ------------------------------ Key: JBCACHE-911 URL: http://jira.jboss.com/jira/browse/JBCACHE-911 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani I don't see any external use for this class in 2.0 and think it's quite ugly. There is no way to configure the behavior. Users shouldn't use it anyway. Places it is called: * NodeImpl.getOrCreateChild() -> I'm thinking that adding a "template method" to say AbstractNode protected abstract Node createNode(Fqn child_fqn, Node parent, TreeCache x); would be good. OptimisticNode or WorkspaceNode can obviously override this. * TreeCache {}: Since it's configuration driven, map an "enum" to a series of "new NodeXYZ()" statements. * OptimisticXYZInterceptor : Create factory methods in TransactionWorkspace * DefaultStateTransferIntegrator : ?? Node target = factory.createDataNode(nodeType, name, fqn, parent, nd.getAttributes(), false, null, cache.getCacheSPI()); ((DataNode) parent).addChild(name, target); Should simply be able to call parent.addChild(name) here. There is the (small) optimization of reusing the attribute Map directly, but this is probably a premature optimization. Or, maybe just parent.put(name, nd.getAttributes()) ? -- 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: (JBTM-188) ConcurrentModificationException during commit time Synchronization processing

by Jonathan Halliday (JIRA)

ConcurrentModificationException during commit time Synchronization processing ----------------------------------------------------------------------------- Key: JBTM-188 URL: http://jira.jboss.com/jira/browse/JBTM-188 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3 Environment: java 1.5, linux, TS 4.2.3.CR2 jta Reporter: Jonathan Halliday Assigned To: Jonathan Halliday Fix For: 4.2.3 When a Synchronization's beforeCompletion method registers another Synchrinization to the transaction, Bad Things happen. 12:38:20,062 ERROR [STDERR] java.util.ConcurrentModificationException 12:38:20,092 ERROR [STDERR] at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1031) 12:38:20,092 ERROR [STDERR] at java.util.TreeMap$KeyIterator.next(TreeMap.java:1058) 12:38:20,092 ERROR [STDERR] at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoP haseCoordinator.java:211) 12:38:20,092 ERROR [STDERR] at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinat or.java:88) 12:38:20,092 ERROR [STDERR] at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177) 12:38:20,092 ERROR [STDERR] at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitA ndDisassociate(TransactionImple.java:1204) 12:38:20,112 ERROR [STDERR] at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(B aseTransaction.java:134) 12:38:20,112 ERROR [STDERR] at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransacti onManagerDelegate.java:87) 12:38:20,112 ERROR [STDERR] at org.jboss.test.cmp2.ageout.test.JDBC2PmAgeOutUnitTestCase.commitTx(JDBC2PmA geOutUnitTestCase.java:236) -- 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] Closed: (JBCACHE-565) Optimistic locking - cache.exists() refers to the tree while cache.get() refers to the workspace

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-565?page=all ] Manik Surtani closed JBCACHE-565. --------------------------------- Resolution: Done > Optimistic locking - cache.exists() refers to the tree while cache.get() refers to the workspace > ------------------------------------------------------------------------------------------------ > > Key: JBCACHE-565 > URL: http://jira.jboss.com/jira/browse/JBCACHE-565 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Manik Surtani > Assigned To: Manik Surtani > Fix For: 2.0.0.BETA1 > > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > This is apparent when used within a tx: > txManager.begin(); > cache.put("/test", "testKey", "Somevalue"); > assertNotNull(cache.get("/test", "testKey")); > assertTrue(cache.exists("/test")); // should return true but returns false instead since the workspace hasn't been committed back to the tree yet -- 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] Commented: (JBCACHE-565) Optimistic locking - cache.exists() refers to the tree while cache.get() refers to the workspace

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-565?page=comments#action_12351037 ] Manik Surtani commented on JBCACHE-565: --------------------------------------- Fixed. exists() is now an internal API anyway, which directly returns peek(fqn, false) != null The equivalent public API is Node.hasChild(), which returns getChild() != null > Optimistic locking - cache.exists() refers to the tree while cache.get() refers to the workspace > ------------------------------------------------------------------------------------------------ > > Key: JBCACHE-565 > URL: http://jira.jboss.com/jira/browse/JBCACHE-565 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Manik Surtani > Assigned To: Manik Surtani > Fix For: 2.0.0.BETA1 > > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > This is apparent when used within a tx: > txManager.begin(); > cache.put("/test", "testKey", "Somevalue"); > assertNotNull(cache.get("/test", "testKey")); > assertTrue(cache.exists("/test")); // should return true but returns false instead since the workspace hasn't been committed back to the tree yet -- 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: (JBESB-157) Socket listeners might introduce a port conflict when reinstantiated by the controlling GpListener at parameter reload time

by Esteban Schifman (JIRA)

Socket listeners might introduce a port conflict when reinstantiated by the controlling GpListener at parameter reload time --------------------------------------------------------------------------------------------------------------------------- Key: JBESB-157 URL: http://jira.jboss.com/jira/browse/JBESB-157 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: ESB Core Reporter: Esteban Schifman Assigned To: Esteban Schifman Fix For: 4.0 GpListener has at present two mechanisms to reload it's configuration parameters: a) timer driven 2) message driven. At parameter reload time, the controlling instance of GpListener will try to instantiate new child processes according to the new configuration values. It will allow active child threads to gracetully finish. New listener classes that are accepting connections on specific sockets will have a conflict when the new instance tries to listen on a port that is being used by the active instance. -- 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
7
0 / 0

Su empresa en la web desde 50.000 pesos

by Pymebiz.com

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-908) Marshalling for state transfer should go thru the VersionAwareMarshaller fwk

by Manik Surtani (JIRA)

Marshalling for state transfer should go thru the VersionAwareMarshaller fwk ---------------------------------------------------------------------------- Key: JBCACHE-908 URL: http://jira.jboss.com/jira/browse/JBCACHE-908 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Replication Affects Versions: 2.0.0.ALPHA1 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.GA I've just noticed that marshalling of nodes for transferring state in HEAD is hand-wired. We should do this thru the VersionAwareMarshaller framework we have in place for other comms as well as marshalling to cache loaders, to benefit from the data streams being version-aware as well as being more efficient by making use of magic numbers instead of class headers + using JBoss Serialization where useful. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-869) Use Marshaller for all forms of serialization, not just replication.

by Manik Surtani (JIRA)

Use Marshaller for all forms of serialization, not just replication. -------------------------------------------------------------------- Key: JBCACHE-869 URL: http://jira.jboss.com/jira/browse/JBCACHE-869 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.ALPHA2 Use Marshallers for all forms of serialization in JBC, including cache loaders. -- 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: (JGRP-367) Common, shared, thread pool for all non transport related threads

by Bela Ban (JIRA)

Common, shared, thread pool for all non transport related threads ----------------------------------------------------------------- Key: JGRP-367 URL: http://jira.jboss.com/jira/browse/JGRP-367 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 All house-keeping threads (like timer threads) should be requested from a configurable thread pool which is global for those threads. Potentially make that thread pool static, so multiple instances of JGroups run in the same VM share the thread pool -- 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