January 2007 - jboss-jira - Jboss List Archives

Cialis (Super Viagra) for $1.99 per pill

by Penelope Bartley

19 years, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1768) Isolating the test harness

by Ryan Campbell (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1768?page=all ] Ryan Campbell updated JBAS-1768: -------------------------------- JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=63341 Let's move the discussion to the forum. > Isolating the test harness > -------------------------- > > Key: JBAS-1768 > URL: http://jira.jboss.com/jira/browse/JBAS-1768 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: JBossAS-4.0.1 Final, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Assigned To: Pavel Tsekov > Fix For: JBossAS-4.2.1.CR1 > > > Since some projects are already using the test harness > org.jboss.test (from the testsuite) > this needs to be isolated to break the circular build dependency. > Additionally, we should look at making this available to users > 1) For their own use > 2) When reporting problems -- 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] Closed: (JBCACHE-137) Packaging of JBossCache lib

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-137?page=all ] Manik Surtani closed JBCACHE-137. --------------------------------- Resolution: Done > Packaging of JBossCache lib > --------------------------- > > Key: JBCACHE-137 > URL: http://jira.jboss.com/jira/browse/JBCACHE-137 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently under JBossCache module lib, there is a jboss-j2ee.jar. But in jboss-head, it was split into jboss-j2ee.jar and jboss-j2se.jar. So for example, in release 1.2.2, we have both new jars. > We will either need to update this or just get rid of the dependency totally. > Other jars which need to be revisited: > jboss-jmx.jar > jboss-minimal.jar > jboss-system.jar -- 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

COMO MEJORAR LA GESTION DE SU EMPRESA?

by EVA ORTEGA CHANDIA

19 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-313) MBeans need to be added for SAR deployment based on new ListenerManager code

by Tom Fennelly (JIRA)

MBeans need to be added for SAR deployment based on new ListenerManager code ---------------------------------------------------------------------------- Key: JBESB-313 URL: http://jira.jboss.com/jira/browse/JBESB-313 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Adapters Affects Versions: 4.0 RC1 Reporter: Tom Fennelly Assigned To: Esteban Schifman Priority: Blocker Fix For: 4.0 The deprecated EsbListenerController code provides MBeans to support SAR deployment. The new ListenerManager replacement code also needs to support this either by evolving the existing MBeans, or starting from scratch with new ones. -- 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

3
6
0 / 0

[JBoss JIRA] Closed: (JBCACHE-595) Merge API interfaces

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-595?page=all ] Manik Surtani closed JBCACHE-595. --------------------------------- Resolution: Done > Merge API interfaces > -------------------- > > Key: JBCACHE-595 > URL: http://jira.jboss.com/jira/browse/JBCACHE-595 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP1 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Blocker > Fix For: 2.0.0.ALPHA2, 2.0.0.GA > > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > * Merge TreeCacheListener, EnhancedTreeCacheListener, add an API to pass in data > * Merge CacheLoader + ExtendedCacheLoader -- 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: (JBESB-318) Add Transformation quickstarts

by Tom Fennelly (JIRA)

Add Transformation quickstarts ------------------------------ Key: JBESB-318 URL: http://jira.jboss.com/jira/browse/JBESB-318 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 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, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-598) Core is not indexing beta memory for Strings and Dates

by Edson Tirelli (JIRA)

Core is not indexing beta memory for Strings and Dates ------------------------------------------------------ Key: JBRULES-598 URL: http://jira.jboss.com/jira/browse/JBRULES-598 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.5 Reporter: Edson Tirelli Assigned To: Edson Tirelli [19:36] <edar> I think that you need to see the rule - just a sec.... [19:37] <edar> URL: http://rafb.net/p/bnWvC837.html [19:37] <tirelli> ok, what is the question? [19:38] <edar> The example program seems to be iterating through all instances of MappedPID when, in this case, there is only a single instance that will satisfy a given BloombergEquityPrice [19:38] <edar> I was expecting MappedPID to be indexed on cusip [19:39] <edar> What I mean is that given a BloombergEquityPrice with ID_CUSIP=12345, there's only a single MappedPID with that cusip [19:40] <tirelli> yes, this should be using indexing [19:40] <edar> Good :-) [19:40] <edar> Whew..... [19:40] <tirelli> what version of jbrules are you using? how do you know it is iterating over them all? [19:41] <edar> In my test, I can vary the number of instances of MappedPID and see that the test run time varys proportionally with the number of MappedPID instances. [19:41] <edar> I'm using the latest download from JBoss [19:41] <tirelli> stable, you mean? (3.0.5) [19:42] <edar> yes, I just checked, 3.0.5 [19:42] <edar> I can easily package up my test case and send it to you if you want. [19:42] <tirelli> ok, depends where you are taking your times [19:42] <tirelli> please :) [19:42] <tirelli> it will be faster [19:42] <tirelli> also, how many instances of BloombergEquityPrice are you asserting? [19:43] <edar> I'm just looking at the total elapsed time for the entire process and then calculating how many 'mappings' per second. [19:43] <edar> I'm asserting 10K MappedPID and 10K BloombergEquityPrice. It only takes sub-seconds to assert all of the MappedPID [19:43] <tirelli> it's important to note that the assert time will increase with additional assertions... [19:44] <edar> The assert time is minimal. If I just take out the mapping part of the rule, the asserts are VERY fast. [19:44] <tirelli> so, if you exclude the assert time, the variation in matches/second should not be that much... [19:44] <tirelli> edar, best way to check is disable indexing and run again [19:45] <tirelli> you will see a big difference if indexing is turned off [19:45] <edar> It's huge. For example, for 1K prices/mappings, I see about 4500K/second mappings. For 10K of each, I see 300/second [19:46] <edar> I have tried all of the variants of indexing with about the same results [19:46] <edar> Is there any kind of logging that will show me exactly what is going on with indexing and if it is being used? [19:47] <tirelli> edar, run a test with -Dorg.drools.reteoo.beta.index-right=true and another with -Dorg.drools.reteoo.beta.index-right=false [19:47] <tirelli> what is the difference? [19:47] <edar> I did that and I saw, basically, no difference. [19:47] <edar> I have the exact numbers here. Just a sec. [19:47] <tirelli> hmm... strange... in this case we may have a problem [19:47] <tirelli> can you send me your test? JBoss Rules 3.0.5 is not indexing beta memory for String and Dates. Add support for that. -- 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] Commented: (JBAS-3310) Remotely initiated sessions are not cleared from the JBoss Cache upon expiration

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3310?page=comments#action_12349490 ] Brian Stansberry commented on JBAS-3310: ---------------------------------------- The original comment on this issue focused on the fact that remote sessions would not be cleared in some edge cases. A likely much larger issue resulting from the same code error is that an expiration check for every remote session will be performed once per check of a single locally active session. Thus if there were 1,000 locally active sessions, and 1,000 remote sessions, a session expiration run would end up doing 1,000,000 remote session expiration checks. This is a potentially very significant overhead. > Remotely initiated sessions are not cleared from the JBoss Cache upon expiration > -------------------------------------------------------------------------------- > > Key: JBAS-3310 > URL: http://jira.jboss.com/jira/browse/JBAS-3310 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Clustering > Affects Versions: JBossAS-4.0.4.GA > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Minor > Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1 > > > Any http session that is in the JBoss Cache due to remote replication but which has not been accessed locally will not be cleared by the Tomcat background thread. -- 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] Closed: (JBCACHE-541) Create one true Node class; that's lean and mean and stuff

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-541?page=all ] Manik Surtani closed JBCACHE-541. --------------------------------- Resolution: Done > Create one true Node class; that's lean and mean and stuff > ---------------------------------------------------------- > > Key: JBCACHE-541 > URL: http://jira.jboss.com/jira/browse/JBCACHE-541 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > Assigned To: Manik Surtani > Fix For: 2.0.0.ALPHA2, 2.0.0.GA > > > There are TreeNode, AbstractNode, DataNode and Node as basically Node types. > I'm thinking as a simplification in design, that a single Node.java class that's concrete and has a fairly comprehensive but non-bloated method set. This will save on memory and reduce confusion. Also, having interfaces for data classes is fairly difficult, as you end up having so many data accessor methods that it is hard to maintain. > The end result would be something like: > public class Node > { > private Fqn fqn; // name is Fqn.getLast() > private Map attributes; > private Map children; > private Lock lock; > } > Note: No parent, no reference to TreeCache (clients can supply it if they want, no need for every node to have a reference), external locking is done on the Lock, internal locking is done on "this". > For all the locking that needs done, create a NodeLock utility class that has these methods, including ten versions of printLocks. :-) > I'll create a list of tasks, some possibly now without breaking compatibility, some for later (like post 2.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, 4 months

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