[JBoss JIRA] (WFCORE-351) CLI "revert to snapshot" command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-351?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-351:
-----------------------------------------
[~kabirkhan] This is more a question about WFCORE-1052, but I'll ask here as this one is recently active.
What happens in terms of persistence and in terms of :shutdown(restart=true), where the script relaunches the vm passing in the original command line params?
Can the user switch from, say, standalone.xml to standalone-full.xml?
The right behavior re: persistence and script driven restart would probably be different when reloading to a snapshot vs switching the base file.
I'm not sure why someone would switch the base file; perhaps some offline CLI type thing where they are tweaking multiple configs. A corner case.
> CLI "revert to snapshot" command
> --------------------------------
>
> Key: WFCORE-351
> URL: https://issues.jboss.org/browse/WFCORE-351
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: all
> Reporter: Rich Sharples
> Assignee: Kabir Khan
> Labels: eap6-ux
> Fix For: 3.0.0.Alpha1
>
>
> The CLI has commands for taking snapshots, listing snapshots, deleting snapshots but no way to rollback or revert to a previous snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Ali Hopyar (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Ali Hopyar commented on JGRP-1914:
----------------------------------
Is there any progress about this issue. We have a bucket in Frankfurt and unfortunately we can not reach it via s3ping :(
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JASSIST-262) Class compilation error - Inconsistent stackmap
by Andrei Ivanov (JIRA)
[ https://issues.jboss.org/browse/JASSIST-262?page=com.atlassian.jira.plugi... ]
Andrei Ivanov commented on JASSIST-262:
---------------------------------------
A release would be nice, if you find a bit of time :)
Thank you
> Class compilation error - Inconsistent stackmap
> -----------------------------------------------
>
> Key: JASSIST-262
> URL: https://issues.jboss.org/browse/JASSIST-262
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: org.javassist:javassist:3.20.0-GA
> java version "1.8.0_74"
> Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)
> Linux 3.13.0-37-generic #64-Ubuntu SMP x86_64 GNU/Linux
> Reporter: Alexey Kuznetsov
> Assignee: Shigeru Chiba
> Fix For: 3.21.0-GA
>
>
> {code:java}
> package com.company;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtMethod;
> public class Main {
> public static void main(String[] args) {
> CtClass badClass = ClassPool.getDefault().makeClass("badClass");
> String src = String.join(System.getProperty("line.separator"),
> "public void eval () {",
> " if (true) {",
> " double t=0;",
> " } else {",
> " double t=0;",
> " }",
> " for (int i=0; i < 2; i++) {",
> " int a=0;",
> " int b=0;",
> " int c=0;",
> " int d=0;",
> " if (true) {",
> " int e = 0;",
> " }",
> " }",
> "}");
> System.out.println(src);
> try {
> badClass.addMethod(CtMethod.make(src, badClass));
> Class clazzz = badClass.toClass();
> Object obj = clazzz.newInstance(); // <-- falls here
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> After running that i get output:
> {noformat}
> public void eval () {
> if (true) {
> double t=0;
> } else {
> double t=0;
> }
> for (int i=0; i < 2; i++) {
> int a=0;
> int b=0;
> int c=0;
> int d=0;
> if (true) {
> int e = 0;
> }
> }
> }
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 41
> Exception Details:
> Location:
> badClass.eval()V @41: iinc
> Reason:
> Type top (current frame, locals[4]) is not assignable to integer (stack map, locals[4])
> Current Frame:
> bci: @35
> flags: { }
> locals: { 'badClass', top, top, top, top, integer, integer, integer, integer, integer }
> stack: { integer }
> Stackmap Frame:
> bci: @41
> flags: { }
> locals: { 'badClass', top, top, top, integer, integer, integer, integer, integer }
> stack: { }
> Bytecode:
> 0x0000000: 0499 0009 0387 48a7 0006 0387 4a03 3605
> 0x0000010: 1505 05a2 001c 0336 0603 3607 0336 0803
> 0x0000020: 3609 0499 0006 0336 0a84 0501 a7ff e4b1
> 0x0000030:
> Stackmap Table:
> same_frame(@10)
> same_frame(@13)
> full_frame(@16,{Object[#2],Top,Top,Top,Top,Integer},{})
> full_frame(@41,{Object[#2],Top,Top,Top,Integer,Integer,Integer,Integer,Integer},{})
> full_frame(@47,{Object[#2],Top,Top,Top,Top,Integer},{})
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
> at java.lang.Class.getConstructor0(Class.java:3075)
> at java.lang.Class.newInstance(Class.java:412)
> at com.company.Main.main(Main.java:31)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Process finished with exit code 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6123?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6123:
---------------------------------
Fix Version/s: 10.1.0.Final
> Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6123
> URL: https://issues.jboss.org/browse/WFLY-6123
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Radoslav Husar
> Priority: Trivial
> Fix For: 10.1.0.Final
>
>
> The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}:
> bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA.
> However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values:
> - {{NONE}}
> - {{BATCH}}
> - {{NON_XA}}
> - {{NON_DURABLE_XA}}
> - {{FULL_XA}}
> I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1499) logging custom-handler does not load module with slot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1499?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1499:
-------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1349223|https://bugzilla.redhat.com/show_bug.cgi?id=1349223] from ASSIGNED to POST
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFCORE-1499
> URL: https://issues.jboss.org/browse/WFCORE-1499
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Erwan Lacoste
> Assignee: James Perkins
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1625) Operation description is not complete in :read-resource-description
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1625?page=com.atlassian.jira.plugi... ]
Jeff Mesnil reassigned WFCORE-1625:
-----------------------------------
Assignee: Jeff Mesnil (was: Brian Stansberry)
> Operation description is not complete in :read-resource-description
> -------------------------------------------------------------------
>
> Key: WFCORE-1625
> URL: https://issues.jboss.org/browse/WFCORE-1625
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The ouput of :read-resource-description is missing some metadata for operations compared to :read-operation-description:
> {noformat}
> [domain@localhost:9990 /] /profile=default:read-resource-description(operations=true)
> {
> "outcome" => "success",
> "result" => {
> "description" => "A named set of subsystem configurations.",
> ...
> "operations" => {
> ...
> "read-attribute-group-names" => {
> "operation-name" => "read-attribute-group-names",
> "description" => "Gets the names of all the attribute groups under the selected resource",
> "request-properties" => {},
> "reply-properties" => {
> "type" => LIST,
> "value-type" => STRING
> }
> },
> ...
> }
> [domain@localhost:9990 /] /profile=default:read-operation-description(name=read-attribute-group-names)
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "read-attribute-group-names",
> "description" => "Gets the names of all the attribute groups under the selected resource",
> "request-properties" => {},
> "reply-properties" => {
> "type" => LIST,
> "value-type" => STRING
> },
> "read-only" => true,
> "runtime-only" => true
> }
> }
> {noformat}
> At least read-only and runtime-only metadata are missing (when they are set on the operation).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla edited comment on WFLY-6781 at 6/30/16 4:37 AM:
-----------------------------------------------------------------
Node1 is where we have domain controller. So domain.xml is only configured on Node1. Node2 is the host controller and we have configured the host.xml on Node2.
By the way Node1 is also the host controller too and we have the host.xml configured there too.
This is about a 2 VM (2 Node) cluster.
Thanks,
Preeta
was (Author: kpreeta12):
Node1 is where we have domain controller. So domain.xml is only configured on Node1. Node2 is the host controller and we have configured the host.xml on Node2.
Thanks,
Preeta
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months