January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-309) Remove buildfrom.distribution from trailblazer build.xml

by Kevin Conner (JIRA)

Remove buildfrom.distribution from trailblazer build.xml -------------------------------------------------------- Key: JBESB-309 URL: http://jira.jboss.com/jira/browse/JBESB-309 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.0 RC1 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.0 The trailblazer samples still use the buildfrom.distribution flag to indicate that they are running from within a build. This flag is no longer needed as the jars are now in the same relative location. -- 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, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-597) shouldn't be able to open rule twice in viewer

by Michael Neale (JIRA)

shouldn't be able to open rule twice in viewer ---------------------------------------------- Key: JBRULES-597 URL: http://jira.jboss.com/jira/browse/JBRULES-597 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBJMX-45) ConcurrentModificationException in UnifiedLoaderRepository3

by Steve Gibson (JIRA)

[ http://jira.jboss.com/jira/browse/JBJMX-45?page=comments#action_12349435 ] Steve Gibson commented on JBJMX-45: ----------------------------------- I don't see any links to other issues here, but what happened to the second part of the issue - from the bug description: suspect that there is a second order synchronization problem in the processing of any HashSet retrieved from the packagesMap. The retrieved HashSet may be concurrently modified if a class loader is added or removed while the set is being processed. The modifications to the HashSet's in the packagesMap performed in the add/remove class loader code path are performed while holding the packagesMap lock, but the code in getResourceFromRepository and LoadMgr3.beginLoadTask, which retrieves a package set using the getPackageClassLoaders method, is unsynchronized. Unless there is some other lock that makes this a non-issue, I suspect that fixing the problem will require either making a copy of the HashSet or a moderate amount of code restructuring. I experienced this issue in production last week and tracked it down to LoadMgr3 as described in the issue. Basically, LoadMgr3.beginLoadTask retrieves a Set from the repository (UnifiedLoadRepository3) and uses an iterator to search for the correct classloader. The iterator is coming from java.util.TreeSet, so concurrent modification can occur when an EJB event triggers a class lookup while startup is still occurring. (Sorry if this is all overly vague). We are running JBoss 4.0.2, but I see the problem code in the trunk. Stack Trace (snippet): 2006-12-29 12:13:35,633 INFO [HibernateServiceMBean] stopping service 2006-12-29 12:13:35,636 INFO [STDOUT] Exception in thread "Queue0" 2006-12-29 12:13:35,639 INFO [NamingHelper] JNDI InitialContext properties:{} 2006-12-29 12:13:35,639 INFO [STDOUT] Exception in thread "Queue1" 2006-12-29 12:13:35,639 INFO [STDOUT] java.lang.ExceptionInInitializerError 2006-12-29 12:13:35,641 INFO [STDOUT] at xxx.AgentMQThread.onMessage(AgentMQThread.java:184) 2006-12-29 12:13:35,642 INFO [STDOUT] at xxx.AgentMQThread.run(AgentMQThread.java:67) 2006-12-29 12:13:35,643 INFO [STDOUT] Caused by: java.util.ConcurrentModificationException 2006-12-29 12:13:35,643 INFO [STDOUT] at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1031) 2006-12-29 12:13:35,644 INFO [STDOUT] at java.util.TreeMap$KeyIterator.next(TreeMap.java:1058) 2006-12-29 12:13:35,644 INFO [STDOUT] at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:221) 2006-12-29 12:13:35,645 INFO [STDOUT] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:475) 2006-12-29 12:13:35,645 INFO [STDOUT] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:377) 2006-12-29 12:13:35,645 INFO [STDOUT] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) 2006-12-29 12:13:35,646 INFO [STDOUT] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > ConcurrentModificationException in UnifiedLoaderRepository3 > ----------------------------------------------------------- > > Key: JBJMX-45 > URL: http://jira.jboss.com/jira/browse/JBJMX-45 > Project: JBoss JMX > Issue Type: Bug > Reporter: SourceForge User > Assigned To: Scott M Stark > > SourceForge Submitter: stottos . > The getResourceFromRepository method in > UnifiedLoaderRepository3 does not synchronize access to > the packagesMap and classLoaders fields, unlike all > other accesses to those fields. As a result, if > classes are being loaded at the same time as a resource > is being looked up, a ConcurrentModificationException > can be triggered. > I have attached a proposed patch for this bug. The fix > wraps the uses of packagesMap and classLoaders fields > in the appropriate synchronized blocks. If the all of > the class loaders need to be searched, a copy of the > classLoaders field is made to avoid having to > synchronize while performing the search. The existing > code is inconsistent in the way it makes a copy of the > classLoaders field: new HashSet(classLoaders) versus > classLoaders.clone(). I arbitrarily chose the former, > but whoever fixes the bug might consider making the > code consistent one way or the other. > I suspect that there is a second order synchronization > problem in the processing of any HashSet retrieved from > the packagesMap. The retrieved HashSet may be > concurrently modified if a class loader is added or > removed while the set is being processed. The > modifications to the HashSet's in the packagesMap > performed in the add/remove class loader code path are > performed while holding the packagesMap lock, but the > code in getResourceFromRepository and > LoadMgr3.beginLoadTask, which retrieves a package set > using the getPackageClassLoaders method, is > unsynchronized. Unless there is some other lock that > makes this a non-issue, I suspect that fixing the > problem will require either making a copy of the > HashSet or a moderate amount of code restructuring. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-287) RemotingTest.testConnectionListener() invalid

by Juha Lindfors (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ] Juha Lindfors updated JBMESSAGING-287: -------------------------------------- Fix Version/s: 1.0.3.CR1 (was: 1.0.2.CR1) > RemotingTest.testConnectionListener() invalid > --------------------------------------------- > > Key: JBMESSAGING-287 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287 > Project: JBoss Messaging > Issue Type: Bug > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Juha Lindfors > Priority: Minor > Fix For: 1.0.3.CR1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. > After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-655) Modify release-admin to allow for XARecovery-enabled and non-XARecovery-enabled configurations

by Ovidiu Feodorov (JIRA)

Modify release-admin to allow for XARecovery-enabled and non-XARecovery-enabled configurations ---------------------------------------------------------------------------------------------- Key: JBMESSAGING-655 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-655 Project: JBoss Messaging Issue Type: Sub-task Components: AS Integration Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.0.2.CR1 -- 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, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (JBESB-297) Need for an SQL gateway that does not require altering 'legacy' data in any way

by Esteban Schifman (JIRA)

Need for an SQL gateway that does not require altering 'legacy' data in any way ------------------------------------------------------------------------------- Key: JBESB-297 URL: http://jira.jboss.com/jira/browse/JBESB-297 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 5.0 Reporter: Esteban Schifman Assigned To: Esteban Schifman Priority: Minor Fix For: 4.0 Kurt has made a very valid point a couple of days ago regarding sql gateways. Current SQL gateway requires an 'ad hoc' column in the watched table as an access indicator to avoid concurrency problems and repeated processing of the same event Many legacy applications do not allow tampering with their data model, not even to have your own stored procedures in place, We should try and find a way to have a version of the SqlTableListener that can work without the need to alter in any way (updating, deleting, adding stored procedures, etc.) the legacy database This alternative would also allow to watch legacy 'views' (instead of simply db tables), thus broadening the scope of use of sql gateways. Configuration will be somewhat more complex than our current sql gateway, but I think it's really worthwhile. -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-182) Missing synchronization?

by Mark Little (JIRA)

Missing synchronization? ------------------------ Key: JBTM-182 URL: http://jira.jboss.com/jira/browse/JBTM-182 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3 Reporter: Mark Little Assigned To: Jonathan Halliday Fix For: 4.2.3 In addSynchronization for TwoPhaseCoordinator, the synchronization object is created if it isn't already set: if (_synchs == null) { // Synchronizations should be stored (or at least iterated) in their natural order _synchs = new TreeSet(); } if (_synchs.add(sr)) { result = AddOutcome.AR_ADDED; } However, because multiple threads could be calling the same transaction instance concurrently, shouldn't there be a synchronization around this block? It's possible that two threads could test and try to set the _synchs and because of interleaving one thread creates _synchs after the other thread already has and added it's resource (which would then become garbage). -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPM-813) GraphElement - hibernate - "this==runtimeAction.getGraphElement()"

by Rainer Alfoeldi (JIRA)

GraphElement - hibernate - "this==runtimeAction.getGraphElement()" ------------------------------------------------------------------ Key: JBPM-813 URL: http://jira.jboss.com/jira/browse/JBPM-813 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.2 Reporter: Rainer Alfoeldi Assigned To: Tom Baeyens See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=96099 for the corresponding forums entry (the field below won't accept this link...) Is it possible that GraphElement .... List getRuntimeActionsForEvent(ExecutionContext executionContext, String eventType) { List runtimeActionsForEvent = null; List runtimeActions = executionContext.getProcessInstance().getRuntimeActions(); if (runtimeActions!=null) { Iterator iter = runtimeActions.iterator(); while (iter.hasNext()) { RuntimeAction runtimeAction = (RuntimeAction) iter.next(); // if the runtime-action action is registered on this element and this eventType if ( ( ===>>>>> this==runtimeAction.getGraphElement() <<<<===== ) && (eventType.equals(runtimeAction.getEventType())) ) { // ... add its action to the list of runtime actions if (runtimeActionsForEvent==null) runtimeActionsForEvent = new ArrayList(); runtimeActionsForEvent.add(runtimeAction.getAction()); } } } return runtimeActionsForEvent; } isn't really what you want? If you debug it you will (sometimes) have the situation that this is a straight forward Java Object and runtimeAction.getGraphElement() resolves to a Node$$EnhancerByCGLIB$$xxxxx. Both objects represent the same node (same id, the CGLIB even refs to the 'this' instance in its 'target' field.... but '==' obviously fails. -- 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, 4 months

2
2
0 / 0

We help you to save on the medicines

by Suzette Sneed

19 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-818) removed exception on request of unexisting process file

by Tom Baeyens (JIRA)

removed exception on request of unexisting process file ------------------------------------------------------- Key: JBPM-818 URL: http://jira.jboss.com/jira/browse/JBPM-818 Project: JBoss jBPM Issue Type: Task Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM 3.2 beta 1 no exception should be thrown when a file is asked to the FileDefinition that doesn't exist. -- 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, 4 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