January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-661) Allow flushing of a cluster subset

by Vladimir Blagojevic (JIRA)

Allow flushing of a cluster subset ---------------------------------- Key: JGRP-661 URL: http://jira.jboss.com/jira/browse/JGRP-661 Project: JGroups Issue Type: Feature Request Affects Versions: 2.6, 2.7 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6.2, 2.7 Currently FLUSH always flushes entire cluster membership. We should allow flushing of a cluster subset. Subset flushing requires additional startFlush and possibly stopFlush method. -- 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, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1271) Incompatible API change - Option.clone() should throw CloneNotSupportedException

by Manik Surtani (JIRA)

Incompatible API change - Option.clone() should throw CloneNotSupportedException -------------------------------------------------------------------------------- Key: JBCACHE-1271 URL: http://jira.jboss.com/jira/browse/JBCACHE-1271 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR3 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA Submitted by Brian vai email: "There's been a change in the public API in 2.1.0.CR3: Option.clone() no longer throws CloneNotSupportedException. This may break apps upgrading from 2.0.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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBCACHE-131) Cache Loaders (when unshared, and not used with passivation) Should Persist Transient State Upon Startup

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-131?page=all ] Manik Surtani updated JBCACHE-131: ---------------------------------- Fix Version/s: 2.2.0.GA (was: 2.1.0.GA) (was: 1.4.X) > Cache Loaders (when unshared, and not used with passivation) Should Persist Transient State Upon Startup > -------------------------------------------------------------------------------------------------------- > > Key: JBCACHE-131 > URL: http://jira.jboss.com/jira/browse/JBCACHE-131 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.2 > Reporter: Jimmy Wilson > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.2.0.GA > > Attachments: TreeCache.zip > > > Given the following single, unshared cache loader use case in the TreeCache documentation: > "This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store" > A cache with attached cache loader should persist the transient state of the cache to disk upon startup in order to maintain cache recoverability. > I have modified TreeCache to handle this situation, and I will attach the modified code to this issue. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1265) Option.setCacheModeLocal ineffective for Node.addChild()

by Brian Stansberry (JIRA)

Option.setCacheModeLocal ineffective for Node.addChild() -------------------------------------------------------- Key: JBCACHE-1265 URL: http://jira.jboss.com/jira/browse/JBCACHE-1265 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Brian Stansberry Assigned To: Manik Surtani If you invoke node.addChild(fqn) with a cacheModeLocal=true option in effect, the node addition replicates. This is because NodeInvocationDelegate first does a get call on the cache to check for node existence, and then does the put. The option is cleared from the thread after the get. Adding test o.j.c.option.cachemodelocal.CacheModeLocalTestBase.testAddChild() to show this. -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1069) persistance.xml with <jar-file> looks for jar file in the wrong place

by Magnus Sandberg (JIRA)

persistance.xml with <jar-file> looks for jar file in the wrong place --------------------------------------------------------------------- Key: EJBTHREE-1069 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1069 Project: EJB 3.0 Issue Type: Bug Environment: JBoss AS 4.2.0.GA (Hibernate 3.3.1.GA) Reporter: Magnus Sandberg Fix For: AS 4.2.0 GA When using <jar-file> references in persistance.xml the Ejb3Configuration does not look for the jar relative to the jar with the persistance.xml but relative to from where jboss is started. -- 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, 11 months

3
2
0 / 0

[JBoss JIRA] Created: (JGRP-631) Thread pools shared within the same JVM

by Bela Ban (JIRA)

Thread pools shared within the same JVM --------------------------------------- Key: JGRP-631 URL: http://jira.jboss.com/jira/browse/JGRP-631 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.7 If we have multiple Channels inside the same JVM, we may want to enable sharing of the - default thread pools - OOB thread pools and - timer thread pools This could be enabled by marking a thread pool as 'shared'. Advantage: threads are shared, so we need fewer resources -- 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, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-5137) Upgrade Hibernate Entity Manager to 3.3.2.Beta2 (from 3.3.2.Beta1)

by Dimitris Andreadis (JIRA)

Upgrade Hibernate Entity Manager to 3.3.2.Beta2 (from 3.3.2.Beta1) ------------------------------------------------------------------ Key: JBAS-5137 URL: http://jira.jboss.com/jira/browse/JBAS-5137 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Hibernate service Affects Versions: JBossAS-5.0.0.Beta3 Reporter: Dimitris Andreadis Assigned To: Emmanuel Bernard Fix For: JBossAS-5.0.0.Beta4 A HEM upgrade to resolve: http://opensource.atlassian.com/projects/hibernate/browse/EJB-326 -- 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, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-5160) Use total replication by default for HttpSession replication

by Brian Stansberry (JIRA)

Use total replication by default for HttpSession replication ------------------------------------------------------------ Key: JBAS-5160 URL: http://jira.jboss.com/jira/browse/JBAS-5160 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta4 See parent issue 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

16 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JASSIST-41) javassist.expr.NewExpr.replace(...) fails if created object is not assigned to variable

by Martin Burger (JIRA)

javassist.expr.NewExpr.replace(...) fails if created object is not assigned to variable --------------------------------------------------------------------------------------- Key: JASSIST-41 URL: http://jira.jboss.com/jira/browse/JASSIST-41 Project: Javassist Issue Type: Bug Environment: Eclipse Reporter: Martin Burger Assigned To: Shigeru Chiba I implemented a ExprEditor that replaces new expressions. However, if the editor should replace a constructor call whose return value (the newly created object) is not assigned to a local variable, the method javassist.expr.NewExpr.canReplace(...) throws a CannotCompileException "sorry, cannot edit NEW followed by no DUP". The constructor has one parameter of type String, the method looks like that one: public void trigger() { new C("some string"); } In the byte code (Eclipse compiler) of the method that contains that constructor call is a LDC before the expected INVOKESPECIAL, so the method canReplace(...) fails: NEW C LDC "some string" INVOKESPECIAL C.<init>(Ljava/lang/String;)V If I add an assignment, there will be a DUP before the LDC: public void trigger() { C c = new C("some string"); } NEW C DUP LDC "some string" INVOKESPECIAL C.<init>(Ljava/lang/String;)V -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-5068) Possible NullPointerException in DistributedReplicantManager#_add()

by Takayoshi Kimura (JIRA)

Possible NullPointerException in DistributedReplicantManager#_add() ------------------------------------------------------------------- Key: JBAS-5068 URL: http://jira.jboss.com/jira/browse/JBAS-5068 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA Reporter: Takayoshi Kimura Assigned To: Brian Stansberry Priority: Minor DistributedReplicantManager#_add() can be called before asynchHandler initialization when multiple nodes starts simultaneously. It results NullPointerException below: 2007-11-09 20:40:17,315 ERROR [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] _add failed java.lang.NullPointerException at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._add(DistributedReplicantManagerImpl.java:622) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:1126) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777) at org.jgroups.JChannel.up(JChannel.java:1091) Impact: Nothing so far, just appearing the ERROR log above. To reproduce this: It's very hard to reproduce. Insert Thread.sleep() call before asynchHandler initialization in DistributedReplicantManager#start() and boot multiple nodes simultaneously. DistributedReplicantManager#start(): // Create the asynch listener handler thread Thread.sleep(10000); asynchHandler = new AsynchEventHandler(this, "AsynchKeyChangeHandler"); asynchHandler.start(); -- 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, 11 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008