[JBoss JIRA] (DROOLS-3373) [DMN Designer] Need Palette glyph/icon and Canvas shape for Decision Service
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3373?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3373:
-----------------------------------
Attachment: 1.5-1.png
2-1.5.png
3-1.5.png
> [DMN Designer] Need Palette glyph/icon and Canvas shape for Decision Service
> ----------------------------------------------------------------------------
>
> Key: DROOLS-3373
> URL: https://issues.jboss.org/browse/DROOLS-3373
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: VisualDesign, drools-tools, ux_needed, visualdesign
> Fix For: 7.17.0.Final
>
> Attachments: 1.5-1.png, 2-1.5.png, 3-1.5.png, DMN_palette_icons.png, DROOLS-3373-Node-Types.png, DecisionService-insitu.png, Screenshot from 2019-01-14 10-48-32.png, decision-service.svg, decision.svg, decision_palette.svg, decision_service_expanded_palette.svg, decision_service_palette.svg
>
>
> We need a new "Palette" icon and Canvas shape for "Decision Services".
> See Table 1: DRD components in the [DMN 1.2 Specification|https://www.omg.org/spec/DMN/1.2/Beta1/PDF].
> See also 6.2.5 Decision service for some narrative regarding the shape.
> {quote}
> A Decision Service is represented in a DRD as rectangle with rounded corners, drawn with a heavy solid border.... the Decision Service SHALL be divided into two parts with a straight solid line.
> {quote}
> We are currently adding support for the _expanded_ form however we will also require (at some stage) a Palette glyph/icon and Canvas shape for the _collapsed_ form too.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11621) Upgrade Weld to 3.1.0.Final
by Matej Novotny (Jira)
[ https://issues.jboss.org/browse/WFLY-11621?page=com.atlassian.jira.plugin... ]
Matej Novotny updated WFLY-11621:
---------------------------------
Description:
Weld 3.1.0.Final release is scheduled in early Feb, so this is a tracking issue for now. It is going to bump the minor version of Weld core and API as it contains several API/SPI changes and will need adjustments on WFLY side.
Namely it:
* Brings new API for class(WELD-2556) defining which will leverage jboss-modules ({{ClassDefiner}}
** This will need impl on WFLY side ([draft on my branch|https://github.com/manovotn/wildfly/tree/weld2556]) assuming jboss-modules 1.9 makes it to WFLY in time
** Required for any JDK 12 execution with Weld
* Removes deprecated code from API/SPI (WELD-2558)
** Requires few removals in WFLY code ([done on this branch|https://github.com/manovotn/wildfly/tree/weld2558])
* Brings new API for CDI context propagation (WELD-2497)
** This is no-op for WFLY as it doesn't use this API
* [plus some changes on Weld core side]
was:
Weld 3.1.0.Final release is scheduled in early Feb, so this is a tracking issue for now. It is going to bump the minor version of Weld core and API as it contains several API/SPI changes and will need adjustments on WFLY side.
Namely it:
* Brings new API for class(WELD-2556) defining which will leverage jboss-modules ({{ClassDefiner}}
** This will need impl on WFLY side ([draft on my branch|https://github.com/manovotn/wildfly/tree/weld2556]) assuming jboss-modules 1.9 makes it to WFLY in time
** Required for any JDK 12 execution with Weld
* Removes deprecated code from API/SPI (WELD-2558)
** Requires few removals in WFLY code ([done on this branch|https://github.com/manovotn/wildfly/tree/weld2558])
* Brings new API for CDI context propagation (WELD-2497)
** This is no-op for WFLY as it doesn't use this API
> Upgrade Weld to 3.1.0.Final
> ---------------------------
>
> Key: WFLY-11621
> URL: https://issues.jboss.org/browse/WFLY-11621
> Project: WildFly
> Issue Type: Component Upgrade
> Components: CDI / Weld
> Affects Versions: 15.0.1.Final
> Reporter: Matej Novotny
> Assignee: Matej Novotny
> Priority: Major
> Fix For: 16.0.0.CR1
>
>
> Weld 3.1.0.Final release is scheduled in early Feb, so this is a tracking issue for now. It is going to bump the minor version of Weld core and API as it contains several API/SPI changes and will need adjustments on WFLY side.
> Namely it:
> * Brings new API for class(WELD-2556) defining which will leverage jboss-modules ({{ClassDefiner}}
> ** This will need impl on WFLY side ([draft on my branch|https://github.com/manovotn/wildfly/tree/weld2556]) assuming jboss-modules 1.9 makes it to WFLY in time
> ** Required for any JDK 12 execution with Weld
> * Removes deprecated code from API/SPI (WELD-2558)
> ** Requires few removals in WFLY code ([done on this branch|https://github.com/manovotn/wildfly/tree/weld2558])
> * Brings new API for CDI context propagation (WELD-2497)
> ** This is no-op for WFLY as it doesn't use this API
> * [plus some changes on Weld core side]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11621) Upgrade Weld to 3.1.0.Final
by Matej Novotny (Jira)
Matej Novotny created WFLY-11621:
------------------------------------
Summary: Upgrade Weld to 3.1.0.Final
Key: WFLY-11621
URL: https://issues.jboss.org/browse/WFLY-11621
Project: WildFly
Issue Type: Component Upgrade
Components: CDI / Weld
Affects Versions: 15.0.1.Final
Reporter: Matej Novotny
Assignee: Matej Novotny
Fix For: 16.0.0.CR1
Weld 3.1.0.Final release is scheduled in early Feb, so this is a tracking issue for now. It is going to bump the minor version of Weld core and API as it contains several API/SPI changes and will need adjustments on WFLY side.
Namely it:
* Brings new API for class(WELD-2556) defining which will leverage jboss-modules ({{ClassDefiner}}
** This will need impl on WFLY side ([draft on my branch|https://github.com/manovotn/wildfly/tree/weld2556]) assuming jboss-modules 1.9 makes it to WFLY in time
** Required for any JDK 12 execution with Weld
* Removes deprecated code from API/SPI (WELD-2558)
** Requires few removals in WFLY code ([done on this branch|https://github.com/manovotn/wildfly/tree/weld2558])
* Brings new API for CDI context propagation (WELD-2497)
** This is no-op for WFLY as it doesn't use this API
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11619) HA Singleton will not stop the service or deployment after merge the cluster-view if the elected node rejected by FullGC or suspended
by Wolf-Dieter Fink (Jira)
[ https://issues.jboss.org/browse/WFLY-11619?page=com.atlassian.jira.plugin... ]
Wolf-Dieter Fink commented on WFLY-11619:
-----------------------------------------
Note if the same happen with a network issue, so both nodes are detecting the split, the merge will stop the deployment/service for one of the nodes.
The message is like this:
INFO [org.wildfly.clustering.server] (ChannelCommandDispatcherFactory - 1) WFLYCLSV0002: This node will no longer operate as the singleton provider of the jboss.deployment.unit."ha-singleton-deployment.jar".installer service
WARNING [class org.jboss.as.quickstarts.ha.singleton.SingletonTimer] (ServerService Thread Pool -- 72) SingletonTimer is stopping: the server is either being shutdown or another node has become elected to be the singleton master.
> HA Singleton will not stop the service or deployment after merge the cluster-view if the elected node rejected by FullGC or suspended
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11619
> URL: https://issues.jboss.org/browse/WFLY-11619
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 16.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: node1.log, node2.log
>
>
> If a 2 node cluster has a HA Singleton deployment (no matter whether it is a service or deployment) a merge after a split caused by FullGC will end in running two nodes as a Singleton provider.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11605) Slave Artemis in Wildfly 10.1.0.Final is starting without Master Shutdown - Split brain
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11605?page=com.atlassian.jira.plugin... ]
Srinivas ev commented on WFLY-11605:
------------------------------------
My project uses Wildfly 10.1.0.Final, and is slated for release this week.
So, need to see the possibilities over this version of Wildfly.
> Slave Artemis in Wildfly 10.1.0.Final is starting without Master Shutdown - Split brain
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11605
> URL: https://issues.jboss.org/browse/WFLY-11605
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: https://developer.jboss.org/thread/279503
> Attachments: Project component log.txt, Wildfly error abrupt failback.txt
>
>
> Scenario - Master, and Slave Running on 2 VM's.
> Master Wildfly - <replication-master cluster-name="my-cluster" group-name="srini-queues-cluster-group" check-for-live-server="true"/>
> Slave Wildfly - <replication-slave cluster-name="my-cluster" group-name="srini-queues-cluster-group" allow-failback="false" max-saved-replicated-journal-size="1"/>
> PFB below 2 errors.
> At this time Slave will start deploying Queues even when Master wildfly is not stopped completely. Both management consoles can be reached.
> Ideally, the Master server(Wildfly) should completely stop for Slave to start the deployment of queues and start the replication.
> 2019/01/16 19:56:21,118+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224044: error acknowledging message: java.lang.NullPointer
> Exception
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.removeReferenceByID(ServerConsumerImpl.java:811)
> 2019/01/16 19:56:21,121+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224016: Caught exception: ActiveMQIllegalStateException[er
> rorType=ILLEGAL_STATE message=null]
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.individualAcknowledge(ServerConsumerImpl.java:772)
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.individualAcknowledge(ServerSessionImpl.java:739)
> Detailed logs are attached.
> At this stage, 1st component in my project pipeline has identified the slave as master now and stick with sending messages to it. Whereas the other components in the pipeline still consuming from Master(based on consumer count).
> This caused the break-in message flow.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11605) Slave Artemis in Wildfly 10.1.0.Final is starting without Master Shutdown - Split brain
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11605?page=com.atlassian.jira.plugin... ]
Srinivas ev edited comment on WFLY-11605 at 1/21/19 7:57 AM:
-------------------------------------------------------------
My project uses Wildfly 10.1.0.Final, and is slated for release this week.
So, need help/suggestions over the possibilities in this version of Wildfly.
was (Author: ev.srinivas):
My project uses Wildfly 10.1.0.Final, and is slated for release this week.
So, need to see the possibilities over this version of Wildfly.
> Slave Artemis in Wildfly 10.1.0.Final is starting without Master Shutdown - Split brain
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11605
> URL: https://issues.jboss.org/browse/WFLY-11605
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: https://developer.jboss.org/thread/279503
> Attachments: Project component log.txt, Wildfly error abrupt failback.txt
>
>
> Scenario - Master, and Slave Running on 2 VM's.
> Master Wildfly - <replication-master cluster-name="my-cluster" group-name="srini-queues-cluster-group" check-for-live-server="true"/>
> Slave Wildfly - <replication-slave cluster-name="my-cluster" group-name="srini-queues-cluster-group" allow-failback="false" max-saved-replicated-journal-size="1"/>
> PFB below 2 errors.
> At this time Slave will start deploying Queues even when Master wildfly is not stopped completely. Both management consoles can be reached.
> Ideally, the Master server(Wildfly) should completely stop for Slave to start the deployment of queues and start the replication.
> 2019/01/16 19:56:21,118+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224044: error acknowledging message: java.lang.NullPointer
> Exception
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.removeReferenceByID(ServerConsumerImpl.java:811)
> 2019/01/16 19:56:21,121+05:30 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224016: Caught exception: ActiveMQIllegalStateException[er
> rorType=ILLEGAL_STATE message=null]
> at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.individualAcknowledge(ServerConsumerImpl.java:772)
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.individualAcknowledge(ServerSessionImpl.java:739)
> Detailed logs are attached.
> At this stage, 1st component in my project pipeline has identified the slave as master now and stick with sending messages to it. Whereas the other components in the pipeline still consuming from Master(based on consumer count).
> This caused the break-in message flow.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months