[JBoss JIRA] (DROOLS-3327) Duplicate an instance
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3327?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3327:
--------------------------------------
[~uxdlc], it looks good to me, I think the issue can be moved to the Resolved state. Regarding the _"Also support duplicate for scenario rows?"_ question: if I understand correctly and there's not anything new behind this, this feature is already supported (rows in the table can be duplicated).
> Duplicate an instance
> ---------------------
>
> Key: DROOLS-3327
> URL: https://issues.jboss.org/browse/DROOLS-3327
> Project: Drools
> Issue Type: Sub-task
> Components: Test Scenarios Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: multiDO.png
>
>
> As a user I want to be able to duplicate a Given/Expect statement (column) so that I can create a statement with an instance of the same data object.
> *_ refer to [parent jira|https://issues.jboss.org/browse/DROOLS-3193] for details and documentation. _
> _Note: The "duplicate" action is possible only for "instance" header (not for single property)._
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-9876) ActiveMQ Artemis with IPv6 and Scope fails
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-9876?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-9876:
--------------------------------------
[~poppjens] Thanks, fix got to Artemis 2.6.0. As Wildfly 14 contains Artemis 2.6.3 which contains the fix I'll mark this jira as resolved. Thanks a lot for reporting this issue.
> ActiveMQ Artemis with IPv6 and Scope fails
> ------------------------------------------
>
> Key: WFLY-9876
> URL: https://issues.jboss.org/browse/WFLY-9876
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: CentOS 7 with IPv6 ULA Address as server for Wildfly 10.1.0Final
> Windows 10 as client
> Both with Java 8u161 (64bit)
> Reporter: Jens Popp
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 14.0.0.Final
>
>
> Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
> {code}
> Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
> while (interfaces.hasMoreElements()) {
> NetworkInterface netInterface = interfaces.nextElement();
> Enumeration<InetAddress> address = netInterface.getInetAddresses();
> while (address.hasMoreElements()) {
> InetAddress addr = address.nextElement();
> if (addr instanceof Inet6Address) {
> Inet6Address inet6addr = (Inet6Address) addr;
> if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
> System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
> }
> }
> }
> {code}
> In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
> If I lookup the JMS from a ULA address (without scope) e.g. with:
> {code}
> String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
> Context context = getApplicationManager().getConnectionHandler().getContext();
> TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
> {code}
> The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
> There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
> I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-9876) ActiveMQ Artemis with IPv6 and Scope fails
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-9876?page=com.atlassian.jira.plugin.... ]
Miroslav Novak resolved WFLY-9876.
----------------------------------
Resolution: Done
> ActiveMQ Artemis with IPv6 and Scope fails
> ------------------------------------------
>
> Key: WFLY-9876
> URL: https://issues.jboss.org/browse/WFLY-9876
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: CentOS 7 with IPv6 ULA Address as server for Wildfly 10.1.0Final
> Windows 10 as client
> Both with Java 8u161 (64bit)
> Reporter: Jens Popp
> Assignee: Jeff Mesnil
> Priority: Major
>
> Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
> {code}
> Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
> while (interfaces.hasMoreElements()) {
> NetworkInterface netInterface = interfaces.nextElement();
> Enumeration<InetAddress> address = netInterface.getInetAddresses();
> while (address.hasMoreElements()) {
> InetAddress addr = address.nextElement();
> if (addr instanceof Inet6Address) {
> Inet6Address inet6addr = (Inet6Address) addr;
> if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
> System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
> }
> }
> }
> {code}
> In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
> If I lookup the JMS from a ULA address (without scope) e.g. with:
> {code}
> String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
> Context context = getApplicationManager().getConnectionHandler().getContext();
> TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
> {code}
> The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
> There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
> I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-9876) ActiveMQ Artemis with IPv6 and Scope fails
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-9876?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFLY-9876:
---------------------------------
Fix Version/s: 14.0.0.Final
> ActiveMQ Artemis with IPv6 and Scope fails
> ------------------------------------------
>
> Key: WFLY-9876
> URL: https://issues.jboss.org/browse/WFLY-9876
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: CentOS 7 with IPv6 ULA Address as server for Wildfly 10.1.0Final
> Windows 10 as client
> Both with Java 8u161 (64bit)
> Reporter: Jens Popp
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 14.0.0.Final
>
>
> Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
> {code}
> Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
> while (interfaces.hasMoreElements()) {
> NetworkInterface netInterface = interfaces.nextElement();
> Enumeration<InetAddress> address = netInterface.getInetAddresses();
> while (address.hasMoreElements()) {
> InetAddress addr = address.nextElement();
> if (addr instanceof Inet6Address) {
> Inet6Address inet6addr = (Inet6Address) addr;
> if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
> System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
> }
> }
> }
> {code}
> In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
> If I lookup the JMS from a ULA address (without scope) e.g. with:
> {code}
> String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
> Context context = getApplicationManager().getConnectionHandler().getContext();
> TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
> {code}
> The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
> There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
> I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-9639) Messages are stuck in a Queue that is configured on HornetQ
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-9639?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-9639.
--------------------------------
Resolution: Rejected
> Messages are stuck in a Queue that is configured on HornetQ
> -----------------------------------------------------------
>
> Key: WFLY-9639
> URL: https://issues.jboss.org/browse/WFLY-9639
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.x.x TBD
> Environment: RHEL 7.2, JDK 1.8_144
> Reporter: Rajendra Mallampati
> Assignee: Jeff Mesnil
> Priority: Major
>
> We use WildFly 9.0.2 for hosting our web application and it has both real time and batch processing components. One of the functions supported on the web includes uploading a file with a number of lines any where from 1 to 10K, If the file is valid (virus scan etc passed) it is parsed into that may messages and published to a queue. Each message will have two counters total number of messages that are published to the queue, and the message number.
> The consuming side is implemented using Spring DefaultMessageListenerContainer (DMLC) with a concurrency of 50 and maxConcurrency of 75. The listeners that implement MessageListener interface are integrated into DMLC. sometimes, if the producing side published 100 messages the consuming side only receiving 98 (per say) and gets stuck because two more messages should be in the Queue. Those two messages are not delivered and don't know where they are going. We tried even persistent Queues and the result is same (getting stuck).
> This is happening in production and any insight into this issue is highly appreciated.
> Here are the software details:
> App server : Wildfly 9.0.2
> HornetQ : 2.4.7
> JDK : 1_8_144
> If you need additional details I will be very glad to provide.
> Thanks
> Rajendra
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-9639) Messages are stuck in a Queue that is configured on HornetQ
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-9639?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-9639:
--------------------------------------
[~rmallamp] Ok, thanks for update. I'll close this jira.
> Messages are stuck in a Queue that is configured on HornetQ
> -----------------------------------------------------------
>
> Key: WFLY-9639
> URL: https://issues.jboss.org/browse/WFLY-9639
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.x.x TBD
> Environment: RHEL 7.2, JDK 1.8_144
> Reporter: Rajendra Mallampati
> Assignee: Jeff Mesnil
> Priority: Major
>
> We use WildFly 9.0.2 for hosting our web application and it has both real time and batch processing components. One of the functions supported on the web includes uploading a file with a number of lines any where from 1 to 10K, If the file is valid (virus scan etc passed) it is parsed into that may messages and published to a queue. Each message will have two counters total number of messages that are published to the queue, and the message number.
> The consuming side is implemented using Spring DefaultMessageListenerContainer (DMLC) with a concurrency of 50 and maxConcurrency of 75. The listeners that implement MessageListener interface are integrated into DMLC. sometimes, if the producing side published 100 messages the consuming side only receiving 98 (per say) and gets stuck because two more messages should be in the Queue. Those two messages are not delivered and don't know where they are going. We tried even persistent Queues and the result is same (getting stuck).
> This is happening in production and any insight into this issue is highly appreciated.
> Here are the software details:
> App server : Wildfly 9.0.2
> HornetQ : 2.4.7
> JDK : 1_8_144
> If you need additional details I will be very glad to provide.
> Thanks
> Rajendra
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-9876) ActiveMQ Artemis with IPv6 and Scope fails
by Jens Popp (Jira)
[ https://issues.jboss.org/browse/WFLY-9876?page=com.atlassian.jira.plugin.... ]
Jens Popp commented on WFLY-9876:
---------------------------------
It should be this one:
https://issues.apache.org/jira/browse/ARTEMIS-1701
At least the committed code is for this bug....
> ActiveMQ Artemis with IPv6 and Scope fails
> ------------------------------------------
>
> Key: WFLY-9876
> URL: https://issues.jboss.org/browse/WFLY-9876
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final, 11.0.0.Final
> Environment: CentOS 7 with IPv6 ULA Address as server for Wildfly 10.1.0Final
> Windows 10 as client
> Both with Java 8u161 (64bit)
> Reporter: Jens Popp
> Assignee: Jeff Mesnil
> Priority: Major
>
> Somehow Java behaves differently on Linux and Windows regarding the IPv6 Network Interfaces. With a small programm you can test this:
> {code}
> Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
> while (interfaces.hasMoreElements()) {
> NetworkInterface netInterface = interfaces.nextElement();
> Enumeration<InetAddress> address = netInterface.getInetAddresses();
> while (address.hasMoreElements()) {
> InetAddress addr = address.nextElement();
> if (addr instanceof Inet6Address) {
> Inet6Address inet6addr = (Inet6Address) addr;
> if (!inet6addr.isLinkLocalAddress() && !inet6addr.isLoopbackAddress())
> System.out.println(netInterface.getName() +":"+ inet6addr.isLinkLocalAddress() +":"+ inet6addr +" - "+ inet6addr.getScopedInterface());
> }
> }
> }
> {code}
> In windows the scope will only be set for Link Local, in CentOS also for ULA addresses.
> If I lookup the JMS from a ULA address (without scope) e.g. with:
> {code}
> String JMS_CONNECTION_FACTORY_JNDI = "jms/RemoteConnectionFactory";
> Context context = getApplicationManager().getConnectionHandler().getContext();
> TopicConnectionFactory cf = (TopicConnectionFactory) context.lookup(JMS_CONNECTION_FACTORY_JNDI);
> {code}
> The TopicConnectionFactory is ActiveMQJMSConnectionFactory. This factory receives a TransportConfiguration from the server that includes the server scope (IPv6 Address with NetworkInterface after % e.g. [fd00::d7dc:b4cc:2e2a:ea1%enp0s3]). Trying to create a topic connection with the TopicConnectionFactory will fail, since the client does not know the scope (enp0s3).
> There is a bug fix in NettyConnector (HORNETQ-907) to strip this "%enp0s3" scope, but this BugFix does not work. The fix uses the standard InetAddress methods to parse the host String, which fails, if the host String contains a server scope (network interface) not available on the client. This will only cause an exception, if server and client have different names for the NetworkInterfaces! Testing e.g. on two identical Linux machines will not uncover the problem!
> I think the underlying problem is, that the lookup distributes the server scope in the IPv6 Address. The scope should only be distributed for Link-local Addresses, for all other addresses the scope should be stripped already on the server and not be distributed during lookup.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11235) Server with HA profile bound to 0.0.0.0 sends cluster topology containing this address to client
by Lin Gao (Jira)
[ https://issues.jboss.org/browse/WFLY-11235?page=com.atlassian.jira.plugin... ]
Lin Gao reassigned WFLY-11235:
------------------------------
Assignee: (was: Lin Gao)
> Server with HA profile bound to 0.0.0.0 sends cluster topology containing this address to client
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-11235
> URL: https://issues.jboss.org/browse/WFLY-11235
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Lin Gao
> Priority: Minor
> Labels: downstream_dependency
> Attachments: WFLY-11235-reproducer.zip
>
> Original Estimate: 4 days
> Remaining Estimate: 4 days
>
> Scenario:
> - server-1
> -- Doesn't matter which profile
> -- Doesn't matter which bind address
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> - server-2
> -- On a different machine than server-1
> -- Bound to 0.0.0.0 (important)
> -- Running standalone-ha profile (important)
> - Standalone EJB client invokes a bean server-1, which as a result invokes another bean on server-2. Repeat this multiple times.
> The first invocation goes through correctly, but it can be seen in the log of server-1 that server-2 (10.8.246.90) has sent a cluster topology containing 0.0.0.0:
> {noformat}
> 04:04:24,651 TRACE [org.jboss.ejb.client.remoting] (default task-5) Running callback org.jboss.ejb.protocol.remote.RemoteEJBService$1$1$$Lambda$876/915175573@68823b7b(org.jboss.ejb.protocol.remote.EJBServerChannel(a)707ad04e, org.jboss.as.ejb3.remote.AssociationImpl@3eb54e9a)
> 04:04:24,919 INFO [org.wildfly.naming] (default task-7) WildFly Naming version 1.0.7.Final-redhat-1
> 04:04:24,930 INFO [org.jboss.ejb.client] (default task-7) JBoss EJB Client version 4.0.9.Final-redhat-1
> 04:04:24,941 DEBUG [org.jboss.ejb.client.invocation] (default task-7) Calling invoke(module = /server-side/WhoAmIBean, strong affinity = None, weak affinity = None):
> 04:04:24,948 TRACE [org.jboss.ejb.client.invocation] (default task-7) Calling executeDiscovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None, weak affinity = None)
> 04:04:24,949 TRACE [org.jboss.ejb.client.invocation] (default task-7) Performing any discovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None, weak affinity = None, filter spec = (ejb-module=server-side))
> 04:04:24,952 TRACE [org.jboss.ejb.client.invocation] (default task-7) EJB discovery provider: attempting to connect to configured connection remote+http://10.8.246.90:8080
> 04:04:25,317 DEBUG [org.jboss.ejb.client.invocation] (default task-18) Received CLUSTER_TOPOLOGY(15) message, registering cluster ejb to node localhost
> 04:04:25,319 DEBUG [org.jboss.ejb.client.invocation] (default task-18) Received CLUSTER_TOPOLOGY(15) message block, registering block ::/0 to address /0.0.0.0:8080
> 04:04:25,321 DEBUG [org.jboss.ejb.client.invocation] (default task-19) Received MODULE_AVAILABLE(8) message for module /server-side
> 04:04:25,324 TRACE [org.jboss.ejb.client.invocation] (default task-7) Performed first-match discovery(target affinity(node) = localhost, destination = remote+http://10.8.246.90:8080)
> 04:04:25,325 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from SENDING to SENT (org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:450))
> 04:04:25,326 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from SENT to WAITING (org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:339))
> 04:04:25,345 TRACE [org.jboss.ejb.client] (default task-22) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from WAITING to READY (org.jboss.ejb.client.EJBClientInvocationContext.resultReady(EJBClientInvocationContext.java:646))
> 04:04:25,345 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from READY to CONSUMING (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:546))
> 04:04:25,346 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from CONSUMING to DONE (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:573))
> {noformat}
> After the first invocation, the bean proxy on server-1 sets it affinity to a ClusterAffinity, which means that the next invocation's destination is picked based on the cluster topology (which contains only 0.0.0.0). It will most likely fail, and after this, the affinity seems to be reset back to None, therefore we have a loop where always one invocation works correctly and the following one fails.
> The following is the log observed on server-1 when an invocation tries to go to 0.0.0.0 (so it either fails with connection refused, or server-1 tries to invoke itself in case that it's listening on 0.0.0.0 too)
> {noformat}
> 04:04:26,485 DEBUG [org.jboss.ejb.client.invocation] (default task-24) Calling invoke(module = /server-side/WhoAmIBean, strong affinity = Cluster "ejb", weak affinity = None):
> 04:04:26,485 TRACE [org.jboss.ejb.client.invocation] (default task-24) Calling executeDiscovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None)
> 04:04:26,486 TRACE [org.jboss.ejb.client.invocation] (default task-24) Performing cluster discovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None, filter spec = (&(cluster=ejb)))
> 04:04:26,486 TRACE [org.jboss.ejb.client.invocation] (default task-24) EJB discovery provider: attempting to connect to configured connection remote+http://10.8.246.90:8080
> 04:04:26,488 TRACE [org.jboss.ejb.client.invocation] (default task-24) EJB discovery provider: attempting to connect to cluster ejb connection remote+http://0.0.0.0:8080
> 04:04:26,492 TRACE [org.jboss.ejb.client.invocation] (default task-24) Performed cluster discovery (target affinity = Node "localhost", destination = remote+http://0.0.0.0:8080)
> 04:04:26,493 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENDING to SENT (org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:450))
> 04:04:26,495 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENT to WAITING (org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:339))
> 04:04:26,497 TRACE [org.jboss.ejb.client] (default task-32) Invocation marked failed, state is currently: WAITING
> 04:04:26,498 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from WAITING to CONSUMING (org.jboss.ejb.client.EJBClientInvocationContext.failed(EJBClientInvocationContext.java:975))
> 04:04:26,498 TRACE [org.jboss.ejb.client.invocation] (default task-32) Blacklisting destination (locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None, missing target = remote+http://0.0.0.0:8080)
> 04:04:26,499 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from CONSUMING to SENDING (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:600))
> 04:04:26,499 TRACE [org.jboss.ejb.client.invocation] (default task-32) Calling executeDiscovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None)
> 04:04:26,499 TRACE [org.jboss.ejb.client.invocation] (default task-32) Performing cluster discovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None, filter spec = (&(cluster=ejb)))
> 04:04:26,501 TRACE [org.jboss.ejb.client.invocation] (default task-32) Performed cluster discovery, nodes is empty; trying an initial
> 04:04:26,502 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENDING to SENT (org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:442))
> 04:04:26,503 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENT to READY (org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:380))
> 04:04:26,503 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from READY to CONSUMING (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:546))
> 04:04:26,503 TRACE [org.jboss.ejb.client] (default task-24) Will not retry (requested = false, remaining = 0)
> 04:04:26,504 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from CONSUMING to DONE (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:613))
> 04:04:26,505 ERROR [org.jboss.as.ejb3.invocation] (default task-24) WFLYEJB0034: EJB Invocation failed on component Intermediate for method public abstract java.lang.String example.ejb.WhoAmIBeanRemote.whoAmI(): javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb"
> (... rest of the error omitted, but it is a "connection refused")
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11235) Server with HA profile bound to 0.0.0.0 sends cluster topology containing this address to client
by Lin Gao (Jira)
[ https://issues.jboss.org/browse/WFLY-11235?page=com.atlassian.jira.plugin... ]
Lin Gao reopened WFLY-11235:
----------------------------
> Server with HA profile bound to 0.0.0.0 sends cluster topology containing this address to client
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-11235
> URL: https://issues.jboss.org/browse/WFLY-11235
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Minor
> Labels: downstream_dependency
> Attachments: WFLY-11235-reproducer.zip
>
> Original Estimate: 4 days
> Remaining Estimate: 4 days
>
> Scenario:
> - server-1
> -- Doesn't matter which profile
> -- Doesn't matter which bind address
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> - server-2
> -- On a different machine than server-1
> -- Bound to 0.0.0.0 (important)
> -- Running standalone-ha profile (important)
> - Standalone EJB client invokes a bean server-1, which as a result invokes another bean on server-2. Repeat this multiple times.
> The first invocation goes through correctly, but it can be seen in the log of server-1 that server-2 (10.8.246.90) has sent a cluster topology containing 0.0.0.0:
> {noformat}
> 04:04:24,651 TRACE [org.jboss.ejb.client.remoting] (default task-5) Running callback org.jboss.ejb.protocol.remote.RemoteEJBService$1$1$$Lambda$876/915175573@68823b7b(org.jboss.ejb.protocol.remote.EJBServerChannel(a)707ad04e, org.jboss.as.ejb3.remote.AssociationImpl@3eb54e9a)
> 04:04:24,919 INFO [org.wildfly.naming] (default task-7) WildFly Naming version 1.0.7.Final-redhat-1
> 04:04:24,930 INFO [org.jboss.ejb.client] (default task-7) JBoss EJB Client version 4.0.9.Final-redhat-1
> 04:04:24,941 DEBUG [org.jboss.ejb.client.invocation] (default task-7) Calling invoke(module = /server-side/WhoAmIBean, strong affinity = None, weak affinity = None):
> 04:04:24,948 TRACE [org.jboss.ejb.client.invocation] (default task-7) Calling executeDiscovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None, weak affinity = None)
> 04:04:24,949 TRACE [org.jboss.ejb.client.invocation] (default task-7) Performing any discovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is None, weak affinity = None, filter spec = (ejb-module=server-side))
> 04:04:24,952 TRACE [org.jboss.ejb.client.invocation] (default task-7) EJB discovery provider: attempting to connect to configured connection remote+http://10.8.246.90:8080
> 04:04:25,317 DEBUG [org.jboss.ejb.client.invocation] (default task-18) Received CLUSTER_TOPOLOGY(15) message, registering cluster ejb to node localhost
> 04:04:25,319 DEBUG [org.jboss.ejb.client.invocation] (default task-18) Received CLUSTER_TOPOLOGY(15) message block, registering block ::/0 to address /0.0.0.0:8080
> 04:04:25,321 DEBUG [org.jboss.ejb.client.invocation] (default task-19) Received MODULE_AVAILABLE(8) message for module /server-side
> 04:04:25,324 TRACE [org.jboss.ejb.client.invocation] (default task-7) Performed first-match discovery(target affinity(node) = localhost, destination = remote+http://10.8.246.90:8080)
> 04:04:25,325 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from SENDING to SENT (org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:450))
> 04:04:25,326 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from SENT to WAITING (org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:339))
> 04:04:25,345 TRACE [org.jboss.ejb.client] (default task-22) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from WAITING to READY (org.jboss.ejb.client.EJBClientInvocationContext.resultReady(EJBClientInvocationContext.java:646))
> 04:04:25,345 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from READY to CONSUMING (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:546))
> 04:04:25,346 TRACE [org.jboss.ejb.client] (default task-7) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@5ffb94cb from CONSUMING to DONE (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:573))
> {noformat}
> After the first invocation, the bean proxy on server-1 sets it affinity to a ClusterAffinity, which means that the next invocation's destination is picked based on the cluster topology (which contains only 0.0.0.0). It will most likely fail, and after this, the affinity seems to be reset back to None, therefore we have a loop where always one invocation works correctly and the following one fails.
> The following is the log observed on server-1 when an invocation tries to go to 0.0.0.0 (so it either fails with connection refused, or server-1 tries to invoke itself in case that it's listening on 0.0.0.0 too)
> {noformat}
> 04:04:26,485 DEBUG [org.jboss.ejb.client.invocation] (default task-24) Calling invoke(module = /server-side/WhoAmIBean, strong affinity = Cluster "ejb", weak affinity = None):
> 04:04:26,485 TRACE [org.jboss.ejb.client.invocation] (default task-24) Calling executeDiscovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None)
> 04:04:26,486 TRACE [org.jboss.ejb.client.invocation] (default task-24) Performing cluster discovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None, filter spec = (&(cluster=ejb)))
> 04:04:26,486 TRACE [org.jboss.ejb.client.invocation] (default task-24) EJB discovery provider: attempting to connect to configured connection remote+http://10.8.246.90:8080
> 04:04:26,488 TRACE [org.jboss.ejb.client.invocation] (default task-24) EJB discovery provider: attempting to connect to cluster ejb connection remote+http://0.0.0.0:8080
> 04:04:26,492 TRACE [org.jboss.ejb.client.invocation] (default task-24) Performed cluster discovery (target affinity = Node "localhost", destination = remote+http://0.0.0.0:8080)
> 04:04:26,493 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENDING to SENT (org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:450))
> 04:04:26,495 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENT to WAITING (org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:339))
> 04:04:26,497 TRACE [org.jboss.ejb.client] (default task-32) Invocation marked failed, state is currently: WAITING
> 04:04:26,498 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from WAITING to CONSUMING (org.jboss.ejb.client.EJBClientInvocationContext.failed(EJBClientInvocationContext.java:975))
> 04:04:26,498 TRACE [org.jboss.ejb.client.invocation] (default task-32) Blacklisting destination (locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None, missing target = remote+http://0.0.0.0:8080)
> 04:04:26,499 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from CONSUMING to SENDING (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:600))
> 04:04:26,499 TRACE [org.jboss.ejb.client.invocation] (default task-32) Calling executeDiscovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None)
> 04:04:26,499 TRACE [org.jboss.ejb.client.invocation] (default task-32) Performing cluster discovery(locator = StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb", weak affinity = None, filter spec = (&(cluster=ejb)))
> 04:04:26,501 TRACE [org.jboss.ejb.client.invocation] (default task-32) Performed cluster discovery, nodes is empty; trying an initial
> 04:04:26,502 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENDING to SENT (org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:442))
> 04:04:26,503 TRACE [org.jboss.ejb.client] (default task-32) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from SENT to READY (org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:380))
> 04:04:26,503 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from READY to CONSUMING (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:546))
> 04:04:26,503 TRACE [org.jboss.ejb.client] (default task-24) Will not retry (requested = false, remaining = 0)
> 04:04:26,504 TRACE [org.jboss.ejb.client] (default task-24) Transitioning org.jboss.ejb.client.EJBClientInvocationContext@386576b9 from CONSUMING to DONE (org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:613))
> 04:04:26,505 ERROR [org.jboss.as.ejb3.invocation] (default task-24) WFLYEJB0034: EJB Invocation failed on component Intermediate for method public abstract java.lang.String example.ejb.WhoAmIBeanRemote.whoAmI(): javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "/server-side/WhoAmIBean", view is interface example.ejb.WhoAmIBeanRemote, affinity is Cluster "ejb"
> (... rest of the error omitted, but it is a "connection refused")
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3193) UX to support selection of multiple data/domain object instances
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3193?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3193:
-------------------------------------
[~kkufova] If these 4 items are okay, I wonder if I should make this an Epic instead? It'll probably take a few sprints to complete all 4. I'm not sure if it's okay to have the scope for this keep expanding and requiring it to keep rolling... Wdyt?
> UX to support selection of multiple data/domain object instances
> ----------------------------------------------------------------
>
> Key: DROOLS-3193
> URL: https://issues.jboss.org/browse/DROOLS-3193
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to use multiple instances of the same data object in my test scenarios (multiple instances support) (i.e. scenario with more than one instance of “Person”...), so that I can create a test scenario.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months