[JBoss JIRA] (WFLY-8639) ConnectionFactory.createContext doesn't use user info from Elytron client AuthenticationConfiguration
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-8639?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-8639.
--------------------------------
Resolution: Done
> ConnectionFactory.createContext doesn't use user info from Elytron client AuthenticationConfiguration
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-8639
> URL: https://issues.jboss.org/browse/WFLY-8639
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Josef Cacek
> Assignee: Jeff Mesnil
> Priority: Critical
>
> AuthenticationConfiguration settings are not used for JMS `ConnectionFactory.createContext()` call and the client call fails with:
> {noformat}
> javax.jms.JMSSecurityRuntimeException: AMQ119031: Unable to validate user
> {noformat}
> Code used for testing:
> {code:java}
> AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.EMPTY.useDefaultProviders()
> .allowSaslMechanisms("DIGEST-MD5").useName("guest").usePassword("guest")).run(() -> {
> try {
> // ... initialize naming etc. here
> ConnectionFactory connectionFactory = (ConnectionFactory) namingContext
> .lookup("jms/RemoteConnectionFactory");
> JMSContext context = connectionFactory.createContext();
> } catch (NamingException e) {
> // ...
> }
> });
> {code}
> server log contains:
> {noformat}
> 17:16:54,667 ERROR [org.apache.activemq.artemis.core.server] (default I/O-1) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:69)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-8639) ConnectionFactory.createContext doesn't use user info from Elytron client AuthenticationConfiguration
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-8639?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-8639:
--------------------------------------
Closing as JBEAP-10527 was closed.
> ConnectionFactory.createContext doesn't use user info from Elytron client AuthenticationConfiguration
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-8639
> URL: https://issues.jboss.org/browse/WFLY-8639
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Josef Cacek
> Assignee: Jeff Mesnil
> Priority: Critical
>
> AuthenticationConfiguration settings are not used for JMS `ConnectionFactory.createContext()` call and the client call fails with:
> {noformat}
> javax.jms.JMSSecurityRuntimeException: AMQ119031: Unable to validate user
> {noformat}
> Code used for testing:
> {code:java}
> AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.EMPTY.useDefaultProviders()
> .allowSaslMechanisms("DIGEST-MD5").useName("guest").usePassword("guest")).run(() -> {
> try {
> // ... initialize naming etc. here
> ConnectionFactory connectionFactory = (ConnectionFactory) namingContext
> .lookup("jms/RemoteConnectionFactory");
> JMSContext context = connectionFactory.createContext();
> } catch (NamingException e) {
> // ...
> }
> });
> {code}
> server log contains:
> {noformat}
> 17:16:54,667 ERROR [org.apache.activemq.artemis.core.server] (default I/O-1) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:623)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:69)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-6967) Client connection are not balanced across cluster with any load balancing policy
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-6967?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6967:
--------------------------------------
This was discussed in jira: https://issues.jboss.org/browse/JBEAP-4886?focusedCommentId=13282265&page...
TLDR Based on feedback from DEV, it works as designed.
> Client connection are not balanced across cluster with any load balancing policy
> --------------------------------------------------------------------------------
>
> Key: WFLY-6967
> URL: https://issues.jboss.org/browse/WFLY-6967
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.CR1
> Reporter: Chen Maoqian
> Assignee: Andy Taylor
> Priority: Critical
>
> *Scenario*
> There two nodes in cluster. Nodes in cluster are connected and both nodes have same jms destinations and connection factory defined like the following one
> {noformat}
> <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory" ha="true" connection-ttl="120000" call-timeout="60000" block-on-acknowledge="true" retry-interval="1000" reconnect-attempts="-1" connection-load-balancing-policy-class-name="org.apache.activemq.artemis.api.core.client.loadbalance.RandomConnectionLoadBalancingPolicy"/>
> {noformat}
> There are clients connecting to cluster. With _RandomConnectionLoadBalancingPolicy_, I would expect that connections are randomly distributed among the nodes in cluster. However, when I list connections on both nodes (/subsystem=messaging-activemq/server=default:list-connection-ids), all connections are on one server.
> Method {{private TransportConfiguration selectConnector()}} in class {{ServerLocatorImpl}} checks whether the {{topologyArray}} is null and makes decision between choosing connector to other node in topology or initial connector of connection factory. In method {{private TransportConfiguration selectConnector()}} {{topologyArray}} is still null, so clients make connection using initial connector. It seems like {{topologyArray}} is only updated during {{notifyNodeUp/Down}} methods.
> Could you please explain how is this client connection balancing supposed to work?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-6967) Client connection are not balanced across cluster with any load balancing policy
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-6967?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-6967.
--------------------------------
Resolution: Explained
> Client connection are not balanced across cluster with any load balancing policy
> --------------------------------------------------------------------------------
>
> Key: WFLY-6967
> URL: https://issues.jboss.org/browse/WFLY-6967
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.CR1
> Reporter: Chen Maoqian
> Assignee: Andy Taylor
> Priority: Critical
>
> *Scenario*
> There two nodes in cluster. Nodes in cluster are connected and both nodes have same jms destinations and connection factory defined like the following one
> {noformat}
> <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory" ha="true" connection-ttl="120000" call-timeout="60000" block-on-acknowledge="true" retry-interval="1000" reconnect-attempts="-1" connection-load-balancing-policy-class-name="org.apache.activemq.artemis.api.core.client.loadbalance.RandomConnectionLoadBalancingPolicy"/>
> {noformat}
> There are clients connecting to cluster. With _RandomConnectionLoadBalancingPolicy_, I would expect that connections are randomly distributed among the nodes in cluster. However, when I list connections on both nodes (/subsystem=messaging-activemq/server=default:list-connection-ids), all connections are on one server.
> Method {{private TransportConfiguration selectConnector()}} in class {{ServerLocatorImpl}} checks whether the {{topologyArray}} is null and makes decision between choosing connector to other node in topology or initial connector of connection factory. In method {{private TransportConfiguration selectConnector()}} {{topologyArray}} is still null, so clients make connection using initial connector. It seems like {{topologyArray}} is only updated during {{notifyNodeUp/Down}} methods.
> Could you please explain how is this client connection balancing supposed to work?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-5795:
--------------------------------------
[~msudra] I'm lowering priority as there is no activity. Is this issue still valid with Wildfly 14?
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 10.x.x TBD
>
> Attachments: ClusteredTopicTest.java, domain.xml, domain.xml, host-slave.xml, host.xml, host.xml, master.log, slave.log
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-5795:
---------------------------------
Priority: Major (was: Critical)
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 10.x.x TBD
>
> Attachments: ClusteredTopicTest.java, domain.xml, domain.xml, host-slave.xml, host.xml, host.xml, master.log, slave.log
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-6589) Add attribute to model which will indicate that backup is synchronized with live server
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-6589?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-6589.
--------------------------------
Resolution: Duplicate Issue
> Add attribute to model which will indicate that backup is synchronized with live server
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6589
> URL: https://issues.jboss.org/browse/WFLY-6589
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
>
> If HA is configured with replicated journal then it takes some time to backup to synchronize with live server. Once backup is in sync with live then following information appears in server.log:
> {code}
> 13:20:00,739 INFO [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-457000966)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=bc015b34-fd73-11e5-80ca-1b35f669abb8 is synchronized with live-server.
> 13:20:01,500 INFO [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@41f992ab-83559664)) AMQ221031: backup announced
> {code}
> Reading server logs to see whether backup is in sync is not convinient and user friendly way. Could we add this information to model so it can be detected through CLI command?
> New attribute with name {{synchronized-with-live}} should be added to {{/subsystem=messaging-activemq/server=default/ha-policy=replication-slave}}
> This information can be gathered by calling: {{SharedNothingBackupActivation.isRemoteBackupUpToDate()}}
> Additionally we should provide this attribute also in replicated live server in: {{/subsystem=messaging-activemq/server=default/ha-policy=replication-master}} as Administrator might want to know whether live can be shutdown.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11293) Add attribute to model which will indicate that backup is synchronized with live server
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11293?page=com.atlassian.jira.plugin... ]
Miroslav Novak reopened WFLY-11293:
-----------------------------------
> Add attribute to model which will indicate that backup is synchronized with live server
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-11293
> URL: https://issues.jboss.org/browse/WFLY-11293
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Reporter: Miroslav Novak
> Priority: Critical
>
> If HA is configured with replicated journal then it takes some time to backup to synchronize with live server. Once backup is in sync with live then following information appears in server.log:
> {code}
> 13:20:00,739 INFO [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-457000966)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=bc015b34-fd73-11e5-80ca-1b35f669abb8 is synchronized with live-server.
> 13:20:01,500 INFO [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@41f992ab-83559664)) AMQ221031: backup announced
> {code}
> Reading server logs to see whether backup is in sync is not convinient and user friendly way. Could we add this information to model so it can be detected through CLI command?
> New attribute with name {{synchronized-with-live}} should be added to {{/subsystem=messaging-activemq/server=default/ha-policy=replication-slave}}
> This information can be gathered by calling: {{SharedNothingBackupActivation.isRemoteBackupUpToDate()}}
> Additionally we should provide this attribute also in replicated live server in: {{/subsystem=messaging-activemq/server=default/ha-policy=replication-master}} as Administrator might want to know whether live can be shutdown.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3030) [DMN Designer] Expand / Collapse all
by Guilherme Carreiro (Jira)
[ https://issues.jboss.org/browse/DROOLS-3030?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-3030:
---------------------------------------
Sprint: 2018 Week 45-47
> [DMN Designer] Expand / Collapse all
> ------------------------------------
>
> Key: DROOLS-3030
> URL: https://issues.jboss.org/browse/DROOLS-3030
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Major
> Labels: UX, drools-tools
>
> User should have possibility to easily expand / collapse all data types in the *manage custom data type* dialog.
> h2. Manual acceptance test
> - Expand
> -- All collapsed initially
> -- Something collapsed initially, something expanded already
> -- All expanded already
> - Collapse
> -- All expanded initially
> -- Something expanded initially, something collapsed already
> -- All collapsed already
> - No error warning in browser console log
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months