[JBoss JIRA] (WFLY-3124) JXM PluggableMBeanServerImpl assumes RealmUser principal
by Vojtech Juranek (JIRA)
Vojtech Juranek created WFLY-3124:
-------------------------------------
Summary: JXM PluggableMBeanServerImpl assumes RealmUser principal
Key: WFLY-3124
URL: https://issues.jboss.org/browse/WFLY-3124
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: 8.0.0.Final
Reporter: Vojtech Juranek
Assignee: Kabir Khan
JXM {{PluggableMBeanServerImpl$LogAction}} assumes that {{RealmUser}} principal is present when Subject is not null. This condition is not always met and results into following exception:
{noformat}
Caused by: java.util.NoSuchElementException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929)
at java.util.HashMap$KeyIterator.next(HashMap.java:960)
at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.getCallerUserId(PluggableMBeanServerImpl.java:1250)
at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1233)
at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1158)
at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.queryNames(MBeanServerAuditLogRecordFormatter.java:170)
at org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:871)
at org.infinispan.jmx.JmxUtil.findJmxDomain(JmxUtil.java:127)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3123) Update Java EE APIs
by Shelly McGowan (JIRA)
Shelly McGowan created WFLY-3123:
------------------------------------
Summary: Update Java EE APIs
Key: WFLY-3123
URL: https://issues.jboss.org/browse/WFLY-3123
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EE
Reporter: Shelly McGowan
Assignee: Shelly McGowan
Fix For: 8.0.1.Final
There were a few bug fix releases of the JBoss Java EE API projects to include in WildFly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-450:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1077228
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Michael Anstis
> Priority: Minor
> Fix For: 6.1.0.Beta2
>
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
> text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3112) One can't change history and decay with DynamicLoadBalanceFactorProvider
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from POST to MODIFIED
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
> Key: WFLY-3112
> URL: https://issues.jboss.org/browse/WFLY-3112
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
> Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider history="0">
> <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
> <property name="capacity" value="1000"/>
> <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
> <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
> </custom-load-metric>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
> double decay = 1 / Math.pow(decayFactor, i);
> totalDecay += decay;
> this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
> totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
> // Normalize load with respect to capacity
> this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
> this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
> totalWeight += weight;
> totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
> this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
> WDYT?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from POST to MODIFIED
> deploy directories not cleaned up
> ---------------------------------
>
> Key: WFLY-1547
> URL: https://issues.jboss.org/browse/WFLY-1547
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Shaun Appleton
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
> Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3108:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1076066|https://bugzilla.redhat.com/show_bug.cgi?id=1076066] from POST to MODIFIED
> Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3108
> URL: https://issues.jboss.org/browse/WFLY-3108
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.1.Final
>
>
> The prescribed mechanism for converting a slave HC to master is to:
> 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml).
> 2) Stop the existing master.
> 3) Use the cli to connect to the slave and
> /host=<slavename>:write-local-domain-controller
> 4) Then, in the CLI
> reload --host=<slavename>
> Problem is this fails because the HC expects to have a domain config file "domain.xml".
> 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory)
> at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45]
> at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> ... 3 more
> Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months