[JBoss JIRA] (WFLY-3174) Add view of batch jobs with ability to view
by The Alchemist (JIRA)
[ https://issues.jboss.org/browse/WFLY-3174?page=com.atlassian.jira.plugin.... ]
The Alchemist commented on WFLY-3174:
-------------------------------------
Maybe I'm going crazy, but I can't find where to view the jobs in the console. I was expecting to see a "Batch" subsystem in the Runtime tab.
!admin.console-runtime.png|width=700!
> Add view of batch jobs with ability to view
> -------------------------------------------
>
> Key: WFLY-3174
> URL: https://issues.jboss.org/browse/WFLY-3174
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 9.0.0.CR1
>
> Attachments: admin.console-runtime.png
>
>
> Currently there is no way to view batch jobs for a deployment with in the batch subsystem management. There should be a way to view the batch jobs that have run on various deployments.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5155) Jacorb initializers tag is not transfered to iiop openjdk subystem after migrate operation
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5155?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-5155.
--------------------------------
Resolution: Rejected
Closing as it is not a bug in iiop code.
> Jacorb initializers tag is not transfered to iiop openjdk subystem after migrate operation
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-5155
> URL: https://issues.jboss.org/browse/WFLY-5155
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.0.0.Beta1
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
>
> If I want to migrate ({{/subsystem=jacorb:migrate()}} JacORB subsystem which contains non-default values of {{initializers}} element then that element is not transferred at all.
> {code}
> <subsystem xmlns="urn:jboss:domain:jacorb:1.4">
> <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
> <initializers security="off" transactions="off"/>
> </orb>
> </subsystem>
> {code}
> is transfered to
> {code}
> <subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
> <orb ssl-socket-binding="jacorb-ssl" socket-binding="jacorb"/>
> </subsystem>
> {code}
> {{Security}} element
> jacorb possible values: identity, on, off, client
> openjdk: identity, client, none
> {{Transactions}} element
> jacorb: on, off, spec
> openjdk: full, none, spec
> I'm not sure how the conversion should look like exactly but e.g. I expect that {{off}} could be transfered to {{none}} etc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5156) Can't set attribute client-supports with value MutualAuth and client-requires with value None
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5156?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski resolved WFLY-5156.
----------------------------------
Resolution: Rejected
> Can't set attribute client-supports with value MutualAuth and client-requires with value None
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-5156
> URL: https://issues.jboss.org/browse/WFLY-5156
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.0.0.Beta1
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
>
> Commands
> {code}
> /subsystem=iiop-openjdk:write-attribute(name=client-supports, value=MutualAuth)
> /subsystem=iiop-openjdk:write-attribute(name=server-supports, value=MutualAuth)
> {code}
> {code}
> /subsystem=iiop-openjdk:write-attribute(name=client-requires, value=None
> /subsystem=iiop-openjdk:write-attribute(name=server-requires, value=None)
> {code}
> do nothing. Meaning no change to xml is promoted. If I use value as {{ClientAuth}} then such value is set in xml correctly.
> Not sure if for {{MutualAuth}}/{{None}} is needed some pre-settings but in such case there should be some error/warning.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-4984) Undertow mod_cluster CLI: Display balancer's stickySession, stickySessionRemove, stickySessionForce, waitWorker and maxattempts properties
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4984?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek closed WFLY-4984.
-------------------------------------
Verified.
{code}
"sticky-session" => true,
"sticky-session-cookie" => "JSESSIONID",
"sticky-session-force" => false,
"sticky-session-path" => undefined,
"sticky-session-remove" => false,
{code}
> Undertow mod_cluster CLI: Display balancer's stickySession, stickySessionRemove, stickySessionForce, waitWorker and maxattempts properties
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4984
> URL: https://issues.jboss.org/browse/WFLY-4984
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Minor
> Labels: mod_cluster
> Fix For: 10.0.0.Alpha6
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing CLI management capabilities. It is of {color:green}Minor{color} priority though.
> h3. Display balancer's stickySession, stickySessionRemove, stickySessionForce, waitWorker and maxattempts properties
> At the moment, this is all there is to see as far as *balancer* runtime configuration goes:
> {noformat}
> "balancer" => {
> "qa_balancer" => {"node" => {"worker-2" => {
> "load" => 89,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}},
> ...
> {noformat}
> h3. Call to action
> Display runtime configuration properties for each balancer; especially these concerning session stickiness. It would help users debug their complex highly available environments without having to dauntingly parse DEBUG logs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-4954) Undertow mod_cluster proxy enforces aliases checks a.k.a. UseAlias:true
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4954?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek closed WFLY-4954.
-------------------------------------
Verified in Beta9.
> Undertow mod_cluster proxy enforces aliases checks a.k.a. UseAlias:true
> -----------------------------------------------------------------------
>
> Key: WFLY-4954
> URL: https://issues.jboss.org/browse/WFLY-4954
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha4
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Fix For: 10.0.0.Beta2
>
>
> If one uses hostnames and a worker registers itself e.g. as {{Host=karm.brq.redhat.com}} the Undertow mod_cluster proxy enforces exact alias matching, which corresponds to Apache HTTP Server mod_cluster module implementation directive [UseAlias|http://docs.jboss.org/mod_cluster/1.2.0/html_single/#d0e505] being set to 1 (enforcing).
> h4. Symptoms
> Thus registered worker's context:
> {noformat}
> INFO [io.undertow] (default task-3) registering context /clusterbench, for node worker-1,
> with aliases [default-host, localhost]
> {noformat} causes HTTP 404 errors both while trying to access the context on IP address or hostname.
> This worker: {noformat}INFO [io.undertow] (default task-20) registering context /clusterbench, for node worker-1,
> with aliases [default-host, karm.brq.redhat.com]
> {noformat}, with one of its aliases being {{karm.brq.redhat.com}} could be accessed via the Undertow mod_cluster proxy without problems.
> h4. Call to action
> We need to decide whether this difference in default behaviour is desirable or not and act accordingly.
> WDYT?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5045) Undertow mod_cluster CLI: IllegalArgumentException: value is null on modcluster:read-resource
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5045?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek closed WFLY-5045.
-------------------------------------
Verified in Beta9.
> Undertow mod_cluster CLI: IllegalArgumentException: value is null on modcluster:read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-5045
> URL: https://issues.jboss.org/browse/WFLY-5045
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha6
> Environment: EAP 7.0.0.DR7, Undertow 1.3.0.Beta4
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Blocker
> Fix For: 10.0.0.Beta2
>
>
> *Undertow 1.3.0.Beta3*, *EAP 7.0.0.DR6* worked perfectly with {{modcluster:read-resource}} recursive operations:
> h3. Setup
> # Add socker binding: {{/socket-binding-group=standard-sockets/socket-binding=mod-cluster-adv:add(multicast-address=224.0.1.105,port=65530)}}
> # Configure mod_cluster proxy: {{/subsystem=undertow/configuration=filter/mod-cluster=modcluster:add(advertise-frequency=10000,advertise-path=/,advertise-protocol=http,advertise-socket-binding=mod-cluster-adv,management-socket-binding=http,management-access-predicate=undefined,broken-node-timeout=10,cached-connections-per-thread=5,connection-idle-timeout=60,connections-per-thread=10,health-check-interval=10000,max-request-time=-1,request-queue-size=10,security-key=undefined,security-realm=undefined,worker=default)}}
> # Add mod_cluster filter: {{/subsystem=undertow/server=default-server/host=default-host/filter-ref=modcluster:add()}}
> # As soon as worker connects: {noformat}UT005053: Registering node localhost, connection: ajp://karm.brq.redhat.com:8019/?#
> UT005045: Registering context /clusterbench, for node localhost{noformat}, we try to list the configuration:
> # List configuration including runtime recursively: {{/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}
> h3. Error
> The output of the last aforementioned command with *EAP 7.0.0.DR6, Undertow 1.3.0.Beta3* is:{noformat}
> {
> "outcome" => "success",
> "result" => {
> "advertise-frequency" => 10000,
> "advertise-path" => "/",
> "advertise-protocol" => "http",
> "advertise-socket-binding" => "mod-cluster-adv",
> "broken-node-timeout" => 10,
> "cached-connections-per-thread" => 5,
> "connection-idle-timeout" => 60,
> "connections-per-thread" => 10,
> "health-check-interval" => 10000,
> "management-access-predicate" => undefined,
> "management-socket-binding" => "http",
> "max-request-time" => -1,
> "request-queue-size" => 10,
> "security-key" => undefined,
> "security-realm" => undefined,
> "worker" => "default",
> "balancer" => {"mycluster" => {"node" => {"localhost" => {
> "load" => 81,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}}}
> }
> }{noformat} whereas with *EAP 7.0.0.DR7, Undertow 1.3.0.Beta4*; it is: {noformat}ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "undertow"),
> ("configuration" => "filter"),
> ("mod-cluster" => "modcluster"),
> ("balancer" => "mycluster")
> ]): java.lang.IllegalArgumentException: value is null
> at org.jboss.dmr.ModelNode.<init>(ModelNode.java:162)
> at org.wildfly.extension.undertow.filters.ModClusterBalancerDefinition$3.handleNode(ModClusterBalancerDefinition.java:117)
> at org.wildfly.extension.undertow.filters.ModClusterBalancerDefinition$AbstractBalancerOperation.execute(ModClusterBalancerDefinition.java:173)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:248)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:701)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:841)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:632)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:357)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1235)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320){noformat}It is noteworthy that *until* any worker joins the balancer, the operation works just fine (DR7, Beta4): {noformat}{
> "outcome" => "success",
> "result" => {
> "advertise-frequency" => 10000,
> "advertise-path" => "/",
> "advertise-protocol" => "http",
> "advertise-socket-binding" => "mod-cluster-adv",
> "broken-node-timeout" => 10,
> "cached-connections-per-thread" => 5,
> "connection-idle-timeout" => 60,
> "connections-per-thread" => 10,
> "health-check-interval" => 10000,
> "management-access-predicate" => undefined,
> "management-socket-binding" => "http",
> "max-request-time" => -1,
> "request-queue-size" => 10,
> "security-key" => undefined,
> "security-realm" => undefined,
> "use-alias" => true,
> "worker" => "default",
> "balancer" => undefined
> }
> }{noformat}
> I see this issue as a {color:red}Blocker{color}, because it not only breaks all current test automation but also renders the Undertow mod_cluster proxy CLI hardly usable for any administration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-4992) Undertow mod_cluster CLI: proxy: Display node's Aliases
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4992?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek closed WFLY-4992.
-------------------------------------
Closed. Verified in Beta9.
{code}
"aliases" => [
"default-host",
"localhost"
]
{code}
> Undertow mod_cluster CLI: proxy: Display node's Aliases
> -------------------------------------------------------
>
> Key: WFLY-4992
> URL: https://issues.jboss.org/browse/WFLY-4992
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: mod_cluster
> Fix For: 10.0.0.Beta1
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Display node's Aliases
> At the moment, this is all there is to see:
> {noformat}
> "balancer" => {
> "qa_balancer" => {"node" => {"worker-2" => {
> "load" => 89,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}},
> ...
> {noformat}
> h3. Call to action
> We need to display node's aliases, e.g.
> {noformat}
> Aliases:
> karm.brq.redhat.com
> localhost
> default-host
> {noformat}
> (an example from the current Apache HTTP Server mod_manager implementation)
> {color:red}Blocker{color} priority justification: Numerous Aliases are fundamental to common user environments and they are necessary for several crucial test scenarios. Without this information available via CLI, it would be impossible to manage any Aliases sensitive setup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-4983) Undertow mod_cluster CLI: Display node's protocol://hostname:port
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4983?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek closed WFLY-4983.
-------------------------------------
Verified in Beta9.
> Undertow mod_cluster CLI: Display node's protocol://hostname:port
> -----------------------------------------------------------------
>
> Key: WFLY-4983
> URL: https://issues.jboss.org/browse/WFLY-4983
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha5
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: mod_cluster
> Fix For: 10.0.0.Beta1
>
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Display node's protocol://hostname:port
> At the moment, this is all there is to see:
> {noformat}
> "balancer" => {
> "qa_balancer" => {"node" => {"worker-2" => {
> "load" => 89,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}},
> ...
> {noformat}
> h3. Call to action
> We need to display node's connection details, e.g. {{ajp://karm.brq.redhat.com:8019}} or {{https://192.168.1.100:8009}}.
> I set {color:red}Blocker{color} priority, because without this information available, it is impossible to test anything more than rudimentary smoke-test scenarios. From the user's perspective, inability to identify JVMRoutes (node names) with their connection strings renders any larger enterprise setup very hard to manage and maintain.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-4929) Hornetq failover doesn't work
by Hardy Ferentschik (JIRA)
[ https://issues.jboss.org/browse/WFLY-4929?page=com.atlassian.jira.plugin.... ]
Hardy Ferentschik commented on WFLY-4929:
-----------------------------------------
Is there a work-around for this issue? I am seeing the same issue using Wildfly 9. I am trying to use a symmetrical cluster setup based on this example - https://github.com/foogaro/wildfly-cookbook/tree/master/cluster-jms-repli... (from the _WildFly Cookbook_). When using this setup the initial startup works. I then kill the first node and the backup node takes over. Then I re-start the first node. In some cases even this initial fail-back did not work (not quite sure how to reproduce it though), but if the first fail-back worked and I then stop the first node again, a fail-over does not happen anymore.
I see a {{NullPointerException}} in the logs of the second node (not sure whether they are the cause of the problem):
{noformat}
16:44:26,430 ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:151)
at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:143)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:350)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:225)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1192)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1412)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.ChunkedStreamSinkConduit.invokeFinishListener(ChunkedStreamSinkConduit.java:291)
at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:263)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1561)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1539)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:227)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:128)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:56)
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:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
16:44:26,434 ERROR [org.xnio.listener] (default I/O-7) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:151)
at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:143)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:350)
at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:225)
at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1192)
at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1412)
at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
at io.undertow.conduits.ChunkedStreamSinkConduit.invokeFinishListener(ChunkedStreamSinkConduit.java:291)
at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:263)
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1561)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1539)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:227)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:128)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:56)
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:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
{noformat}
It looks like the fail-over and fail-back does not work consistently and repeatedly.
> Hornetq failover doesn't work
> -----------------------------
>
> Key: WFLY-4929
> URL: https://issues.jboss.org/browse/WFLY-4929
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 9.0.0.Final
> Environment: Fedora 22
> openjdk 8
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Attachments: master.log, master.xml, slave.log, slave.xml
>
>
> I tried to set up backup server for JMS subsystem. I act upon this tutorial (shared store) https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio...
> When I killed the LIVE server, BACKUP server took the control as I expected. However the problem occurred when I started the LIVE server again. LIVE server stopped the BACKUP and then the BACKUP threw an exception. After that warnings started to occur in the log of BACKUP. When I killed the LIVE again, BACKUP didn't take the control again. See attachments.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months