[JBoss JIRA] (DROOLS-3347) Implement Undo/Redo
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-3347:
----------------------------------------
Summary: Implement Undo/Redo
Key: DROOLS-3347
URL: https://issues.jboss.org/browse/DROOLS-3347
Project: Drools
Issue Type: Enhancement
Components: Scenario Simulation and Testing
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Provide actual implementation of undo/redo.
Step:
1) verify that all model modification happen through commands (check "flush" methods inside grid cells and other access to model)
2) implement columns size persistence inside backend model (wrap simulation inside another object to store dimension size)
3) implement actual undo/redo
4) add Undo/Redo buttons
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3346) Method and function invocation passing a field doesn't work in executable model
by Mario Fusco (Jira)
Mario Fusco created DROOLS-3346:
-----------------------------------
Summary: Method and function invocation passing a field doesn't work in executable model
Key: DROOLS-3346
URL: https://issues.jboss.org/browse/DROOLS-3346
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
Using the executable model, trying to invoke a function or static method from a pattern passing a field of the matched class (instead of using an accessor) causes an error message like the following
{code}
Error Messages:
Message [id=1, level=ERROR, path=src/main/java/com/middleware/bzr/ruleset/p2x_acr/r0/Rulese14c4bc3281a47218150a512c4578947RuleMethods0.java, line=160, column=86
text=cannot find symbol
symbol: variable var_S_OPAIR
location: class com.middleware.bzr.ruleset.p2x_acr.r0.Rulese14c4bc3281a47218150a512c4578947RuleMethods0]
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3345) Method and function invocation passing a field doesn't work in executable model
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3345?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-3345:
--------------------------------
Description:
Using the executable model, trying to invoke a function or static method from a pattern passing a field of the matched class (instead of using an accessor) causes an error message like the following
{code}
Error Messages:
Message [id=1, level=ERROR, path=src/main/java/com/middleware/bzr/ruleset/p2x_acr/r0/Rulese14c4bc3281a47218150a512c4578947RuleMethods0.java, line=160, column=86
text=cannot find symbol
symbol: variable var_S_OPAIR
location: class com.middleware.bzr.ruleset.p2x_acr.r0.Rulese14c4bc3281a47218150a512c4578947RuleMethods0]
{code}
> Method and function invocation passing a field doesn't work in executable model
> -------------------------------------------------------------------------------
>
> Key: DROOLS-3345
> URL: https://issues.jboss.org/browse/DROOLS-3345
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Blocker
>
> Using the executable model, trying to invoke a function or static method from a pattern passing a field of the matched class (instead of using an accessor) causes an error message like the following
> {code}
> Error Messages:
> Message [id=1, level=ERROR, path=src/main/java/com/middleware/bzr/ruleset/p2x_acr/r0/Rulese14c4bc3281a47218150a512c4578947RuleMethods0.java, line=160, column=86
> text=cannot find symbol
> symbol: variable var_S_OPAIR
> location: class com.middleware.bzr.ruleset.p2x_acr.r0.Rulese14c4bc3281a47218150a512c4578947RuleMethods0]
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Radoslav Husar reassigned WFLY-11374:
-------------------------------------
Component/s: (was: Clustering)
Assignee: Jeff Mesnil (was: Jason Greene)
> Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: active standalone full ha.xml, master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master-server-linux.log, master-server-windows.log, master.xml, rotateserver_active.log, rotateserver_active.log, rotateserver_backup.log, rotateserver_slave.log, slave standalone full ha.xml, slave-server-linux.log, slave-server-windows.log, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
> Few logs I found which may be impacting and I am not clear -
> 1.2018-11-21 14:28:07,238 TRACE [org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@38e819b6-2112524495)) Setting up bridge between TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-30 and ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-41], discoveryGroupConfiguration=null]: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.<init>(ClusterConnectionBridge.java:129)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.createNewRecord(ClusterConnectionImpl.java:778)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.nodeUP(ClusterConnectionImpl.java:698)
> at org.apache.activemq.artemis.core.client.impl.Topology$1.run(Topology.java:264)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11404) Artemis throws Critical IO Error if new journal file is not created in 5 seconds
by Tomas Hofman (Jira)
[ https://issues.jboss.org/browse/WFLY-11404?page=com.atlassian.jira.plugin... ]
Tomas Hofman moved JBEAP-15904 to WFLY-11404:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11404 (was: JBEAP-15904)
Issue Type: Enhancement (was: Bug)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: ActiveMQ)
Affects Version/s: 15.0.0.Beta1
(was: 7.1.0.DR12)
(was: 7.1.0.DR13)
(was: 7.1.0.DR17)
(was: 7.1.0.DR18)
(was: 7.1.0.DR19)
(was: 7.1.0.ER1)
(was: 7.1.0.CR1)
> Artemis throws Critical IO Error if new journal file is not created in 5 seconds
> --------------------------------------------------------------------------------
>
> Key: WFLY-11404
> URL: https://issues.jboss.org/browse/WFLY-11404
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 15.0.0.Beta1
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Critical
>
> I can see in our CI jobs that Artemis sometimes stops because of error \[1\]. I looked at the code \[2\] where the exception is thrown and I think it could be improved a bit.
> _Customer Impact:_ If Artemis journal is located on slower file system (like NFS) then if server is under load then it might crash. This will lead to unavailability of service. Server must be restarted to recover.
> First thing I noticed is that the 5 seconds timeout is not configurable. I agree that it should be enough in most cases but if someone would want to use NFS for Artemis journal and he doesn't care about performance, we should able him to tune this value. Additionally the timeout doesn't reflect size of journal files.
> Second thing is that when {{openedFiles.poll()}} returns null we can't be sure whether it is problem of exhausted disc or exhausted CPU. I think there should be added some kind of latch which would wait until pushOpenRunnable is executed. It will make sure that there is issue with IO operations and it was not caused by exhausted CPU.
> \[1\]
> {code}
> 09:45:07,418 WARN [org.apache.activemq.artemis.core.server] (Thread-10 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$4@2646099c-962838060)) AMQ222010: Critical IO Error, shutting down the server. file=NULL, message=unable to open : ActiveMQIOErrorException[errorType=IO_ERROR message=AMQ149003: File not opened]
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.openFile(JournalFilesRepository.java:423) [artemis-journal-1.5.3.002-redhat-1.jar:1.5.3.002-redhat-1]
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.moveNextFile(JournalImpl.java:2885) [artemis-journal-1.5.3.002-redhat-1.jar:1.5.3.002-redhat-1]
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.switchFileIfNecessary(JournalImpl.java:2842) [artemis-journal-1.5.3.002-redhat-1.jar:1.5.3.002-redhat-1]
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.appendRecord(JournalImpl.java:2568) [artemis-journal-1.5.3.002-redhat-1.jar:1.5.3.002-redhat-1]
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.access$200(JournalImpl.java:87) [artemis-journal-1.5.3.002-redhat-1.jar:1.5.3.002-redhat-1]
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl$4.run(JournalImpl.java:889) [artemis-journal-1.5.3.002-redhat-1.jar:1.5.3.002-redhat-1]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) [artemis-commons-1.5.3.002-redhat-1.jar:1.5.3.002-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
> {code}
> \[2\]
> {code}
> public JournalFile openFile() throws InterruptedException, ActiveMQIOErrorException {
> if (logger.isTraceEnabled()) {
> logger.trace("enqueueOpenFile with openedFiles.size=" + openedFiles.size());
> }
> if (openFilesExecutor == null) {
> pushOpenRunnable.run();
> } else {
> openFilesExecutor.execute(pushOpenRunnable);
> }
> JournalFile nextFile = openedFiles.poll(5, TimeUnit.SECONDS);
> if (nextFile == null) {
> fileFactory.onIOError(ActiveMQJournalBundle.BUNDLE.fileNotOpened(), "unable to open ", null);
> // We need to reconnect the current file with the timed buffer as we were not able to roll the file forward
> // If you don't do this you will get a NPE in TimedBuffer::checkSize where it uses the bufferobserver
> fileFactory.activateBuffer(journal.getCurrentFile().getFile());
> throw ActiveMQJournalBundle.BUNDLE.fileNotOpened();
> }
> if (logger.isTraceEnabled()) {
> logger.trace("Returning file " + nextFile);
> }
> return nextFile;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11394) Wrong units of jvm.uptime metric - milliseconds vs. seconds
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-11394?page=com.atlassian.jira.plugin... ]
Jeff Mesnil resolved WFLY-11394.
--------------------------------
Resolution: Won't Fix
I agree, the unit of the metrics is handled differently by the MP Metrics endpoints.
The JSON format returns the "raw" value and leaves to the client to find the unit by looking at the metrics metadata with the OPTIONS HTTP method.
Prometheus format returns the "base" value (eg seconds for time units) and appends the unit to the metric name.
> Wrong units of jvm.uptime metric - milliseconds vs. seconds
> -----------------------------------------------------------
>
> Key: WFLY-11394
> URL: https://issues.jboss.org/browse/WFLY-11394
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Major
>
> Wrong units of jvm.uptime metric - milliseconds vs. seconds
> {code}
> curl -H "Accept: application/json" -X OPTIONS http://localhost:9990/metrics/base/jvm.uptime
> {
> "jvm.uptime": {
> "unit": "milliseconds",
> "type": "gauge",
> "description": "Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.",
> "displayName": "JVM Uptime",
> "tags": ""
> }
> {code}
> This metric reports results in seconds, not in milliseconds as description says.
> {code}
> curl http://localhost:9990/metrics/base/jvm.uptime
> # HELP base:jvm_uptime_seconds Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.
> # TYPE base:jvm_uptime_seconds gauge
> base:jvm_uptime_seconds 2011.875
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11394) Wrong units of jvm.uptime metric - milliseconds vs. seconds
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/WFLY-11394?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda commented on WFLY-11394:
------------------------------------------
Description was updated via WFLY-11393 so the confusion about milliseconds vs. seconds is close to zero.
There is still the fact that json response returns one format and prometheus response another.
But that's not handle by us, so probably this issue can be closed. [~jmesnil] wdyt ?
> Wrong units of jvm.uptime metric - milliseconds vs. seconds
> -----------------------------------------------------------
>
> Key: WFLY-11394
> URL: https://issues.jboss.org/browse/WFLY-11394
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Major
>
> Wrong units of jvm.uptime metric - milliseconds vs. seconds
> {code}
> curl -H "Accept: application/json" -X OPTIONS http://localhost:9990/metrics/base/jvm.uptime
> {
> "jvm.uptime": {
> "unit": "milliseconds",
> "type": "gauge",
> "description": "Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.",
> "displayName": "JVM Uptime",
> "tags": ""
> }
> {code}
> This metric reports results in seconds, not in milliseconds as description says.
> {code}
> curl http://localhost:9990/metrics/base/jvm.uptime
> # HELP base:jvm_uptime_seconds Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.
> # TYPE base:jvm_uptime_seconds gauge
> base:jvm_uptime_seconds 2011.875
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months