February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-979) Tighten up rethrowing of exceptions

by Brian Stansberry (JIRA)

Tighten up rethrowing of exceptions ----------------------------------- Key: JBCACHE-979 URL: http://jira.jboss.com/jira/browse/JBCACHE-979 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Priority: Minor Look for this kind of stuff: try { doIt(); } catch (Exception e) { throw new RuntimeException(e); } and replace with: try { doIt(); } catch (RuntimeException e) { throw e; } catch (Exception e) { throw new RuntimeException(e); } I wrote a CacheListener that threw a custom runtime exception, expecting to be able to catch it. But the cache wrapped it, messing up my logic and forcing me to catch RuntimeException and check the cause. This particular one was in CacheImpl.invokeMethod() (and will be fixed in a sec). A minor nit. -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBCACHE-471) Handle JGroups MERGE

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-471?page=all ] Manik Surtani updated JBCACHE-471: ---------------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > Handle JGroups MERGE > -------------------- > > Key: JBCACHE-471 > URL: http://jira.jboss.com/jira/browse/JBCACHE-471 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Fix For: 2.1.0.GA > > > When JGroups needs to do a merge due to a temporary break in the group structure, JGroups does not handle the merging of data. This is usually left up to the application to handle. > JBossCache should support pluggable merge policies, we could provide some simple merge policies and allow users to write their own. > 1. Evict on merge policy - when a merge occurs, evict the entire in-memory state. Useful for Hibernate or when used with a shared cache loader. > 2. Other merge algos ... ? -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-194) Provide configurable eviction thread priority boost

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-194?page=all ] Manik Surtani updated JBCACHE-194: ---------------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > Provide configurable eviction thread priority boost > --------------------------------------------------- > > Key: JBCACHE-194 > URL: http://jira.jboss.com/jira/browse/JBCACHE-194 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3 > Reporter: Brian Dueck > Assigned To: Manik Surtani > Fix For: 2.1.0.GA > > Attachments: LRUPolicy.java, LRUPolicy.java, LRUPolicy.java > > > In environments where there there are many TreeCache client threads accessing the cache concurrently, the eviction thread may become starved. In this situation, even setting the wakeupInterval to 1 or 2 seconds does not help because the OS won't allocate proportionally very much time to the waiting eviction thread in comparison to the other TreeCache client threads. > While there are some "fancy" solutions to this problem involving client threads being put to work to perform eviction, or having multiple eviction threads, one solution that help partially alleviate the problem is to boost the thread priority of the eviction thread. > This provides a clue to the OS that allows the eviction thread to be scheduled more CPU time relative to other threads in a CPU resource constrained situation. > This change involves switching from using the Java Timer object to using the Oswego ClockDaemon class instead. I've attached here a protoype implementation that reads a new XML configuration parameter (evictionPriorityBoost - if you can think of a better name, go ahead and rename it) and then boosts the eviction thread priority accordingly. > Here's an example of the new config param: > <attribute name="EvictionPolicyConfig"> > <config> > <attribute name="wakeUpIntervalSeconds">5</attribute> >  > <attribute name="evictionPriorityBoost">2</attribute> >  > <region name="/_default_"> > <attribute name="maxNodes">5000000</attribute> > <attribute name="timeToLiveSeconds">10</attribute> > </region> > </config> > </attribute> -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBPM-621) Decision 'otherwise' choice does not appear to work.

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-621?page=all ] Ronald van Kuijk resolved JBPM-621. ----------------------------------- Fix Version/s: jBPM jPDL 3.2 Resolution: Done By comments of users... The docs are now in line with the behaviour > Decision 'otherwise' choice does not appear to work. > ---------------------------------------------------- > > Key: JBPM-621 > URL: http://jira.jboss.com/jira/browse/JBPM-621 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.1 > Reporter: youngm > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2 > > > The following decision appears to always result in the "to_print" transition choosen. The decision node doesn't appear to ever check transisions who don't have conditions. So it assumes there is only one transition so it chooses the 'default' or first transition. > <decision name="data_needed"> > <transition name="to_print" to="print_application"> > <condition expression="#{true == false}"/> > </transition> > <transition name="to_get_approval" to="get_approval"/> > </decision> -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-209) Expand the JBossCache tutorial page

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-209?page=all ] Manik Surtani updated JBCACHE-209: ---------------------------------- Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial] (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)]) Assignee: Manik Surtani (was: Daniel Huang) > Expand the JBossCache tutorial page > ----------------------------------- > > Key: JBCACHE-209 > URL: http://jira.jboss.com/jira/browse/JBCACHE-209 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.0.0.GA > > > Currently our tutorial page is not up to date with the new features. For example, we should have a eviction tutorial. > On the JbossCacheAop side, we need to have a tutorial that illustrate: > 1. Example to illsutrate the POJO relationship management (person and object, for example) > 2. Annotation based example tutorial > 3. Interaction with CacheLoader (that also hightlight the perservation of relationship) > 4. Illustrate the getObject during failover (from another node) -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-814) Concurrency issue with passivation

by Brian Stansberry (JIRA)

Concurrency issue with passivation ---------------------------------- Key: JBCACHE-814 URL: http://jira.jboss.com/jira/browse/JBCACHE-814 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0.SP1 Reporter: Brian Stansberry Assigned To: Manik Surtani If the eviction thread attempts to passivate a node roughly concurrently with a get() call, it is quite easy for the get() to return null even though the passivated node has data. Test org.jboss.cache.passivation.ConcurrentPassivationTest shows the problem. I believe the problem results from having the PessimisticLockInterceptor in the chain after the Activation and Passivation interceptors. Potential cause is a race to the PessimisticLockInterceptor between the eviction thread and an application thread doing a get(). 1) Eviction thread wins race, acquires a WL on a node. 2) Application thread is trailing in the race but proceeds through the Activation/Passivation interceptors w/o loading data, because the desired node is still in the cache. 3) Application thread blocks waiting for eviction thread's WL to be released. 4) Eviction thread removes the node from the tree structure. 5) Eviction thread releases the WL. Application thread acquires a RL (it already had a ref to the node). 6) Application thread gets to the cache _get method, which can't find the node in the tree structure, and thus returns null. Another variation on the same theme: 1) Eviction thread wins race, acquires a WL on a node. 2) Application thread is trailing in the race but proceeds through the Activation/Passivation interceptors w/o loading data, because the desired node is still in the cache. 3) Eviction thread removes the node from the tree structure. 4) Application thread gets to PessimisticLockInterceptor, which can't find the node. No need to acquire lock on non-existent node, so thread proceeds. 5) Application thread gets to the cache _get method, which can't find the node in the tree structure, and thus returns null. -- 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, 2 months

3
7
0 / 0

[JBoss JIRA] Commented: (JBPM-165) process instance versioning

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-165?page=comments#action_12354609 ] Ronald van Kuijk commented on JBPM-165: --------------------------------------- slipping this to 3.3? Or will it realy still go into 3.2? I would let it slip... > process instance versioning > --------------------------- > > Key: JBPM-165 > URL: http://jira.jboss.com/jira/browse/JBPM-165 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM jPDL 3.2 > > > i think jbpm could offer some degree of assistence in process instance versioning. > when a new version of a process is deployed, jbpm could do the following conversion for a process instance : > * input required: mapping of the nodes from the old to the new definition. > * cancel the old process instance > * create a new process instance and copy the runtime (exe) information such as tokens and process variables from the old process instance. > * then establish a special link between the 2 process instances to indicate that the new process instance is the continuation of the old process instance. > this way we can avoid the problematic conversion of logs, while still keeping them in the system. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-714) packaging just the webapp takes way to long

by Ronald van Kuijk (JIRA)

packaging just the webapp takes way to long ------------------------------------------- Key: JBPM-714 URL: http://jira.jboss.com/jira/browse/JBPM-714 Project: JBoss jBPM Issue Type: Feature Request Affects Versions: jBPM 3.2 alpha 1 Environment: Eclipse 3.2, gpd 3.0.11, jdk 1.5 windhoos Reporter: Ronald van Kuijk Assigned To: Tom Baeyens Fix For: jBPM 3.2 Packaging just the webapp takes 13 seconds. In this time the 'global' compile is used. This results in packaging jbpm-jpdl.jar twice and copying it to the repository twice. This should be optimised in combination with a 'deploy' target which deploys it to a configured location. Even better would be if it is a real WTP web (sub?) project which can have things like 'auto deployment' small updates to .xhtml files available immediately, etc.... -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4161) run.sh/.bat should not compile when running with a JRE

by Dimitris Andreadis (JIRA)

run.sh/.bat should not compile when running with a JRE ------------------------------------------------------ Key: JBAS-4161 URL: http://jira.jboss.com/jira/browse/JBAS-4161 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: System service Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.0.Beta2 Since jboss-web 2.x (tc6) a full JDK with toos.jar is not required anymore for compiling jsp pages, since jboss web packages the eclipse jdt compiler and javassist has its own internal compiler. Modify the run.bat/.sh script to not complain if %JAVA_HOME%\lib\tools.jar is missing, but neverthless, put it in the classpath if exists, in case the user wants to override the default eclipse jdt compiler in the jboss web configuration. -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4119) Consoles and invokers need to accept local connections only unless secured with username/password

by Alex Pinkin (JIRA)

Consoles and invokers need to accept local connections only unless secured with username/password ------------------------------------------------------------------------------------------------- Key: JBAS-4119 URL: http://jira.jboss.com/jira/browse/JBAS-4119 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Alex Pinkin Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 - jmx console - web console - jmx-invoker - rmi/http invoker -- 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, 2 months

2
4
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 February 2007