[JBoss JIRA] (DROOLS-667) Profile why day.index is so much slower than day.getIndex()
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-667?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-667:
------------------------------------
I made the use case to run for a bit longer (100+ seconds) and I cannot reproduce any relevant difference. Using day.index I got this:
2014-12-15 17:03:50,345 [SwingWorker-pool-3-thread-1] INFO Solving ended: time spent (102397), best score (0hard/-815683soft), average calculate count per second (407), environment mode (REPRODUCIBLE).
while with day.getIndex() I have:
2014-12-15 17:06:57,316 [SwingWorker-pool-3-thread-1] INFO Solving ended: time spent (102024), best score (0hard/-815683soft), average calculate count per second (404), environment mode (REPRODUCIBLE).
I pushed an optimization that normalizes a getter (e.g.: 'getIndex()') to the corresponding fieldName (e.g.: 'index') when generating the field accessor inside the PatternBuilder: https://github.com/droolsjbpm/drools/commit/7084221cf
However this optimization is not related with the TravelingTournamentApp use case because all the accessors in that drl need a further level of indirection like in day.index or day.getIndex().
Please try to profile this use case on your machine and figure out what's the difference there.
> Profile why day.index is so much slower than day.getIndex()
> -----------------------------------------------------------
>
> Key: DROOLS-667
> URL: https://issues.jboss.org/browse/DROOLS-667
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR3
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> day.index is 3 times slower than day.getIndex() (and it's gets more as the dataset grows)
> As discussed with Mario. Rough benchmark speeds here:
> https://gist.github.com/ge0ffrey/7662856f357dbec7f7ec
> Reproduce recipe
> - git clone optaplanner
> - Run TravelingTournamentApp, load dataset bra24, solve it for about 30 seconds.
> - Open travelingTournamentScoreRules.drl. Replace all occurrences of "day.getIndex()" with "day.index".
> - Run TravelingTournamentApp again, load dataset bra24, solve it for about 30 seconds again.
> - Compare the last log message of both runs: look for average calculate count per second (x). Higher is faster. For bra24, day.getIndex() is 3 times faster than day.index.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-3623) Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3623?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3623:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1139188|https://bugzilla.redhat.com/show_bug.cgi?id=1139188] from POST to CLOSED
> Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3623
> URL: https://issues.jboss.org/browse/WFLY-3623
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final, 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Bartosz Baranowski
> Attachments: 01134324.jar, dumpServices.txt
>
>
> See attached jar for a reproducer. Just deploy it. The jar includes it's own source.
> An @Resource annotation with a spurious ":" in the name attribute value results in an incorrect binding but no deployment failure:
> {code}
> @Resources({
> @Resource(
> // name="java:jboss/ResourceTestEJB", // ==> this works fine
> name="java:jboss:/ResourceTestEJB", // ==> this will not bind the JNDI correctly, and there is no error on deploying EJB
>
> type=com.test.ResourceEJB.class,
> lookup="java:global/01134324/ResourceEJBImpl")
> })
> {code}
> There is no error reported in the log.
> Using jndi-view op in the CLI, I see:
> {code}
> [standalone@localhost:9990 subsystem=naming] :jndi-view
> {
> "outcome" => "success",
> "result" => {
> "java: contexts" => {
> .....
> "java:jboss" => {
> ....
> "java:jboss:" => {"class-name" => "javax.naming.Context"},
> }
> }
> ....
> }
> {code}
> Any time the jndi-view op is run, the following is logged in the server.log:
> {code}
> 10:52:02,985 ERROR [org.jboss.as.naming] (management-handler-thread - 5) WFLYNAM0013: Failed to obtain jndi view value for entry java:jboss:.: javax.naming.NameNotFoundException: jboss: -- service jboss.naming.context.java.jboss.jboss:
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:132) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:47) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:72) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:603) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:481) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1060) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:296) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:165) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:204) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:133) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:297)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:536)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> If a proper binding can't be done per the annotation value, there should be an exception thrown triggering deployment rollback.
> I'll attach an MSC service dump in case it's useful.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-213:
------------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1163634|https://bugzilla.redhat.com/show_bug.cgi?id=1163634] from ASSIGNED to CLOSED
> Clean unreferenced items from the content repository
> ----------------------------------------------------
>
> Key: WFCORE-213
> URL: https://issues.jboss.org/browse/WFCORE-213
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Alpha14
>
>
> The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example:
> 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed.
> 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed.
> Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4043) Cannot load custom login module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-4043.
------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
Fix Version/s: 9.0.0.Beta1
Resolution: Done
I'm going to treat this as a docs bug and resolve it based on the changes I just made.
> Cannot load custom login module
> -------------------------------
>
> Key: WFLY-4043
> URL: https://issues.jboss.org/browse/WFLY-4043
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 8.1.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4043) Cannot load custom login module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4043:
-----------------------------------
Component/s: Documentation
> Cannot load custom login module
> -------------------------------
>
> Key: WFLY-4043
> URL: https://issues.jboss.org/browse/WFLY-4043
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, Security
> Affects Versions: 8.1.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Jason Greene
>
> When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4043) Cannot load custom login module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4043?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-4043:
----------------------------------------
Definitely! Sorry about that. I've updated the documentation.
> Cannot load custom login module
> -------------------------------
>
> Key: WFLY-4043
> URL: https://issues.jboss.org/browse/WFLY-4043
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Jason Greene
>
> When security realm authentication is configured to use JAAS domain, it is not possible to use custom login module, because there is no loader present for deployed classes. LoginContext attempts to load the login module class and fails with ClassNotFoundException.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years