[JBoss JIRA] (SWSQE-3) Deploy Simple Service-Mesh Configuration
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-3?page=com.atlassian.jira.plugin.sy... ]
Guilherme Baufaker Rêgo updated SWSQE-3:
----------------------------------------
Description: Create a simple Service Mesh which produces "real" data, which will be used for Service Graph validation. (was: Team Saturn Sprint-1 test requirement.
Create a simple Service Mesh which produces "real" data, which will be used for Service Graph validation.)
> Deploy Simple Service-Mesh Configuration
> ----------------------------------------
>
> Key: SWSQE-3
> URL: https://issues.jboss.org/browse/SWSQE-3
> Project: Swift Sunshine QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Matt Mahoney
>
> Create a simple Service Mesh which produces "real" data, which will be used for Service Graph validation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9746) Revert JGroups capability reference to ChannelFactory
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9746?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-9746:
-----------------------------------
[~pferraro] I tried to run your PR against the standalone-full-ha.xml from JBEAP-14164.
(I had to remove some configuration for infinispan that were preventing the server to boot but that do not seem related to this issue).
The server fails to start with the error:
{code}
$ ./bin/standalone.sh -c standalone-full-ha.xml
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/jmesnil/Developer/wildfly/dist/target/wildfly-12.0.0.Alpha1-SNAPSHOT
JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
10:50:55,643 INFO [org.jboss.modules] (main) JBoss Modules version 1.7.0.Beta3
10:50:55,938 INFO [org.jboss.msc] (main) JBoss MSC version 1.3.0.Final
10:50:55,948 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.0.Final
10:50:56,076 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Beta1) starting
10:50:57,458 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
10:50:57,482 INFO [org.wildfly.security] (ServerService Thread Pool -- 6) ELY00001: WildFly Elytron version 1.2.0.Final
10:50:57,483 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'security-domain' in the resource at address '/subsystem=messaging-activemq/server=default' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
10:50:57,483 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 26) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
10:50:57,494 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'jgroups-stack' in the resource at address '/subsystem=messaging-activemq/server=default/broadcast-group=bg-group1' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
10:50:57,496 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'jgroups-stack' in the resource at address '/subsystem=messaging-activemq/server=default/discovery-group=dg-group1' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
10:50:57,523 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 17) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "jgroups"),
("channel" => "udp")
]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[
(\"subsystem\" => \"jgroups\"),
(\"channel\" => \"udp\")
]' as it is already registered in context 'global' at location(s) '[[
(\"subsystem\" => \"jgroups\"),
(\"stack\" => \"udp\")
]]'"
10:50:57,670 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem messaging-activemq boot operations"
10:50:57,672 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem messaging-activemq boot operations\""
10:50:57,676 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
10:50:57,688 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0050: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Beta1) stopped in 5ms
{code}
> Revert JGroups capability reference to ChannelFactory
> -----------------------------------------------------
>
> Key: WFLY-9746
> URL: https://issues.jboss.org/browse/WFLY-9746
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 12.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> There is regression If Artemis is configured to JGroups tcp stack to form cluster then server does not start and fail with:
> {code}
> 13:24:02,424 INFO [org.jboss.ws.common.management] (MSC service thread 1-8) JBWS022052: Starting JBossWS 5.1.9.Final (Apache CXF 3.1.12)
> 13:24:02,428 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "messaging-activemq"),
> ("server" => "default")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => [
> "jboss.messaging-activemq.default",
> "org.wildfly.clustering.command-dispatcher-factory.tcp"
> ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.messaging-activemq.default.jms.manager is missing [jboss.messaging-activemq.default]",
> "jboss.messaging-activemq.default is missing [org.wildfly.clustering.command-dispatcher-factory.tcp]"
> ]
> }
> 13:24:02,438 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.messaging-activemq.default (unavailable) dependents: [service jboss.messaging-activemq.default.jms.manager]
> service org.wildfly.clustering.command-dispatcher-factory.tcp (missing) dependents: [service jboss.messaging-activemq.default]
> 13:24:02,485 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:24:02,487 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:11990/management
> 13:24:02,487 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:11990
> {code}
> Configuration of jgroups and messaging-activemq subsystem:
> {code}
> <subsystem xmlns="urn:jboss:domain:jgroups:5.0">
> <channels default="ee">
> <channel name="ee" stack="udp" cluster="ejb"/>
> </channels>
> ...
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="org.jgroups.protocols.TCPPING">
> <property name="port_range">
> 10
> </property>
> <property name="num_initial_members">
> 1
> </property>
> <property name="initial_hosts">
> 127.0.0.1[9600]
> </property>
> <property name="timeout">
> 3000
> </property>
> </protocol>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </stacks>
> </subsystem>
> ....
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:3.0">
> <server name="default" persistence-enabled="true" id-cache-size="200000">
> <broadcast-group name="bg-group1" jgroups-stack="tcp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
> <discovery-group name="dg-group1" jgroups-stack="tcp" jgroups-channel="udp" refresh-timeout="10000"/>
> <cluster-connection name="my-cluster" address="jms" connector-name="connector" check-period="30000" connection-ttl="60000" call-timeout="30000" discovery-group="dg-group1"/>
> ...
> </server>
> </subsystem>
> {code}
> Attaching the whole config: standalone-full-ha.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-7787) Upgrade RESTEasy to 3.1.0.Final
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-7787?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-7787:
---------------------------------------
[~mariobraga], yes, the upgrade to 3.1 didn't eventually happen, we backported most of the features to 3.0.x and moved to 3.0.24.Final. The problem was basically with retaining full backward compatibility with RESTEasy 2 series.
This said, stay tuned for announcement regarding RESTEasy 3.5 in few days (WildFly 12 is going to include that).
> Upgrade RESTEasy to 3.1.0.Final
> -------------------------------
>
> Key: WFLY-7787
> URL: https://issues.jboss.org/browse/WFLY-7787
> Project: WildFly
> Issue Type: Component Upgrade
> Components: REST
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Fix For: 11.0.0.Alpha1
>
>
> Upgrade RESTEasy from 3.1.0.CR3 to 3.1.0.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9832) the endpoint configuration w/o parameters is not persisted in the configuration
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-9832?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFLY-9832:
------------------------------------
Description:
This looks like a regression. Creating a server config from scratch by executing operations I see that the endpoint configuration has disappeared from the config although the add operation is executed. In fact I noticed that I can execute the add operations as many times as I want w/o an error. The config file is re-written after every add but the endpoint element is not added.
{code:java}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
{code}
{code:java}
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
{code}
Note, that if I add a worker as a param, it will persist the endpoint config.
was:
This looks like a regression. Creating a server config from scratch by executing operations I see that the endpoint configuration has disappeared from the config although the operation adding is executed. In fact I noticed that I can execute the add operations as many times as I want w/o an error. The config file is re-written after every add but the endpoint element is not added.
{code:java}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
{"outcome" => "success"}
{code}
{code:java}
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
{code}
Note, that if I add a worker as a param, it will persist the endpoint config.
> the endpoint configuration w/o parameters is not persisted in the configuration
> -------------------------------------------------------------------------------
>
> Key: WFLY-9832
> URL: https://issues.jboss.org/browse/WFLY-9832
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Reporter: Alexey Loubyansky
> Assignee: David Lloyd
>
> This looks like a regression. Creating a server config from scratch by executing operations I see that the endpoint configuration has disappeared from the config although the add operation is executed. In fact I noticed that I can execute the add operations as many times as I want w/o an error. The config file is re-written after every add but the endpoint element is not added.
> {code:java}
> [standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=remoting/configuration=endpoint:add
> {"outcome" => "success"}
> {code}
> {code:java}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> Note, that if I add a worker as a param, it will persist the endpoint config.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months