[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
17 years, 3 months
[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
17 years, 3 months
[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
17 years, 3 months