[JBoss JIRA] (WFCORE-1557) PropertiesAttributeDefinition unwrap does not properly handle undefined values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1557?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1557:
-------------------------------------
Description:
The unwrap method resolves the value of the map entries but does not check if they are defined before calling asString(). So an undefined value will store as string "undefined" instead of null.
-The class doesn't any way to configure or check whether null is ok; perhaps I'll improve that as well.- <--- was incorrect
was:
The unwrap method resolves the value of the map entries but does not check if they are defined before calling asString(). So an undefined value will store as string "undefined" instead of null.
The class doesn't any way to configure or check whether null is ok; perhaps I'll improve that as well.
> PropertiesAttributeDefinition unwrap does not properly handle undefined values
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1557
> URL: https://issues.jboss.org/browse/WFCORE-1557
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.CR2
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The unwrap method resolves the value of the map entries but does not check if they are defined before calling asString(). So an undefined value will store as string "undefined" instead of null.
> -The class doesn't any way to configure or check whether null is ok; perhaps I'll improve that as well.- <--- was incorrect
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1557) PropertiesAttributeDefinition unwrap does not properly handle undefined values
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1557:
----------------------------------------
Summary: PropertiesAttributeDefinition unwrap does not properly handle undefined values
Key: WFCORE-1557
URL: https://issues.jboss.org/browse/WFCORE-1557
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.2.0.CR2
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The unwrap method resolves the value of the map entries but does not check if they are defined before calling asString(). So an undefined value will store as string "undefined" instead of null.
The class doesn't any way to configure or check whether null is ok; perhaps I'll improve that as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JASSIST-248) Constant pool index 268 is invalid
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-248?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-248.
---------------------------------
> Constant pool index 268 is invalid
> ----------------------------------
>
> Key: JASSIST-248
> URL: https://issues.jboss.org/browse/JASSIST-248
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.19.0-GA
> Reporter: Laurent Pellegrino
> Assignee: Shigeru Chiba
> Labels: regression
> Fix For: 3.21.0-GA
>
> Attachments: _StubLinkedList.class
>
>
> We are using Javassist for one of our open source projects since about 10 years. Recently, I have tried to upgrade to version 3.19 and 3.20. Unfortunately, with both versions, generated byte code seems to cause errors with the JVM.
> Below is the output:
> {code}
> Exception in thread "RestartDownNodesPolicy node status check" java.lang.VerifyError: Illegal type at constant pool entry 268 in class pa.stub.java.util._StubLinkedList
> Exception Details:
> Location:
> pa/stub/java/util/_StubLinkedList.replaceAll(Ljava/util/function/UnaryOperator;)V @43: invokespecial
> Reason:
> Constant pool index 268 is invalid
> Bytecode:
> 0x0000000: 2ab4 00cc 9900 252a b400 0db2 002c 100b
> 0x0000010: 32c0 0028 04bd 00ce 5903 2b53 b200 26b8
> 0x0000020: 00d7 b900 dd02 0057 b12a 2bb7 010c b1
> Stackmap Table:
> same_frame(@41)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.objectweb.proactive.core.mop.MOP.forName(MOP.java:155)
> at org.objectweb.proactive.core.mop.MOP.findStubConstructor(MOP.java:649)
> at org.objectweb.proactive.core.mop.MOP.createStubObject(MOP.java:822)
> at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:338)
> at org.objectweb.proactive.core.mop.MOP.newInstance(MOP.java:196)
> at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reifyAsAsynchronous(AbstractBodyProxy.java:277)
> at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.invokeOnBody(AbstractBodyProxy.java:154)
> at org.objectweb.proactive.core.body.proxy.AbstractBodyProxy.reify(AbstractBodyProxy.java:123)
> at pa.stub.org.ow2.proactive.resourcemanager.nodesource._StubNodeSource.getDownNodes(_StubNodeSource.java)
> at org.ow2.proactive.resourcemanager.nodesource.policy.RestartDownNodesPolicy$1.run(RestartDownNodesPolicy.java:92)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> {code}
> The issue seems related to default methods introduced in Java 8. Perhaps its not an issue with Javassist but to be honest I don't understand the exception. However, I have noticed that using Javassist in version 3.18.2 solves the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JASSIST-262) Class compilation error - Inconsistent stackmap
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-262?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-262:
---------------------------------------
The schedule is not fixed but maybe in June.
> 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, 11 months
[JBoss JIRA] (JGRP-1906) jdbc_ping doesn't delete crashed node
by Mikhail Krestyaninov (JIRA)
[ https://issues.jboss.org/browse/JGRP-1906?page=com.atlassian.jira.plugin.... ]
Mikhail Krestyaninov commented on JGRP-1906:
--------------------------------------------
[~belaban] I'm currently facing the same problem running JGroups with Mesos and Docker. Once these technologies are quite popular today, may be it worth to reconsider the approach for cleaning up the database? E.g. active JGroups members may time to time update (using timestamp) their records and clean up old ones.
> jdbc_ping doesn't delete crashed node
> -------------------------------------
>
> Key: JGRP-1906
> URL: https://issues.jboss.org/browse/JGRP-1906
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: n/a
> Reporter: rama rama
> Assignee: Bela Ban
> Priority: Critical
>
> Hi,
> i am having trouble with jgroups. If a node crash, it doesn't get removed from jdbc table.
> After 10 hours of work, the table contains 100 rows (that is not a problem) but, when the server start_up, GMS take _AGES_ to try to connect to all this dead node.
> Since i am only a 'user' speaking about jgroup and i have no idea on how internally does it work, it this normal?
> I don't think so, master of the cluster, or a governor or something like that, should be able to detect if a node is present or not (via FD,VERIFY_SUSPECT) and delete it from JDBC table to avoid issue on startup for the next time, correct me if i am wrong.
> Here a copy/paste of my current config, configured in applicative way.
> ------------------------------------------------------------------------------------
> int min_cores = 1;
> int max_cores = 50;
> InetAddress bind_addr = org.jgroups.util.Util.getAddressByPatternMatch("match-address:" + Config.get("Cluster.bind_addr"));
> stack
> .addProtocol(new UDP()
> .setValue("bind_addr", bind_addr)
> .setValue("loopback", true)
> .setValue("thread_naming_pattern", "cl")
> .setValue("timer_type", "new3")
> .setValue("timer_min_threads", min_cores)
> .setValue("timer_max_threads", max_cores)
> .setValue("timer_keep_alive_time", Util.MIN * 10)
> .setValue("timer_queue_max_size", 500)
> .setValue("mcast_port", Config.get("Cluster.mcast_port", Constant.INT_NULL))
> .setValue("thread_pool_keep_alive_time", Util.MIN * 10)
> .setValue("thread_pool_min_threads", min_cores)
> .setValue("thread_pool_max_threads", max_cores)
> .setValue("thread_pool_queue_enabled", false)
> .setValue("thread_pool_queue_max_size", 500)
> .setValue("oob_thread_pool_keep_alive_time", Util.MIN * 10)
> .setValue("oob_thread_pool_min_threads", min_cores)
> .setValue("oob_thread_pool_max_threads", max_cores)
> .setValue("oob_thread_pool_queue_enabled", false)
> .setValue("oob_thread_pool_queue_max_size", 500)
> .setValue("internal_thread_pool_keep_alive_time", Util.MIN * 10)
> .setValue("internal_thread_pool_min_threads", min_cores)
> .setValue("internal_thread_pool_max_threads", max_cores)
> .setValue("internal_thread_pool_queue_enabled", false)
> .setValue("internal_thread_pool_queue_max_size", 600000)
> .setValue("ucast_recv_buf_size", org.jgroups.util.Util.readBytesInteger("5M"))
> .setValue("ucast_send_buf_size", org.jgroups.util.Util.readBytesInteger("640K"))
> .setValue("mcast_recv_buf_size", org.jgroups.util.Util.readBytesInteger("5M"))
> .setValue("mcast_send_buf_size", org.jgroups.util.Util.readBytesInteger("640K"))
> )
> .addProtocol(new JDBC_PING()
> .setValue("connection_url", Config.get("DB.dbdriver") + ':' + Config.get("DB.dburl") + '/' + Config.get("DB.dbname"))
> .setValue("connection_username", Config.get("DB.dbuser"))
> .setValue("connection_password", Config.get("DB.dbpwd"))
> .setValue("connection_driver", "org.postgresql.Driver")
> .setValue("initialize_sql", "CREATE TABLE IF NOT EXISTS JGROUPSPING ( own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data bytea DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )")
> )
> .addProtocol(new MERGE3()
> .setValue("max_interval", 10000)
> .setValue("min_interval", 1000)
> )
> .addProtocol(new FD_SOCK()
> .setValue("bind_addr", bind_addr)
> )
> .addProtocol(new FD_ALL()
> )
> .addProtocol(new VERIFY_SUSPECT()
> .setValue("timeout", 1000)
> .setValue("bind_addr", bind_addr)
> )
> .addProtocol(new NAKACK2()
> .setValue("xmit_interval", 500)
> .setValue("xmit_table_num_rows", 100)
> .setValue("xmit_table_msgs_per_row", 2000)
> .setValue("xmit_table_max_compaction_time", 30000)
> .setValue("max_msg_batch_size", 500)
> .setValue("use_mcast_xmit", false)
> .setValue("discard_delivered_msgs", true)
> )
> .addProtocol(new UNICAST3()
> .setValue("xmit_table_num_rows", 100)
> .setValue("xmit_table_msgs_per_row", 1000)
> .setValue("xmit_table_max_compaction_time", 30000)
> .setValue("max_msg_batch_size", 500)
> )
> .addProtocol(new STABLE()
> .setValue("stability_delay", 2000)
> .setValue("desired_avg_gossip", 60000)
> .setValue("max_bytes", org.jgroups.util.Util.readBytesInteger("4M"))
> .setValue("cap", 0.1)
> )
> .addProtocol(new GMS()
> .setValue("join_timeout", 3000)
> .setValue("view_bundling", false)
> .setValue("print_local_addr", false)
> .setValue("print_physical_addrs", false)
> )
> .addProtocol(new UFC()
> .setValue("max_credits", org.jgroups.util.Util.readBytesInteger("4M"))
> .setValue("min_threshold", 0.4)
> )
> .addProtocol(new MFC()
> .setValue("max_credits", org.jgroups.util.Util.readBytesInteger("4M"))
> .setValue("min_threshold", 0.4)
> )
> .addProtocol(new FRAG2()
> .setValue("frag_size", org.jgroups.util.Util.readBytesInteger("60K"))
> )
> .addProtocol(new RSVP()
> .setValue("resend_interval", 2000)
> .setValue("timeout", 10000)
> )
> ;
> stack.init();
> ----------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Cody Ebberson (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Cody Ebberson commented on JGRP-2062:
-------------------------------------
No worries. The workaround is straightforward enough.
I haven't tried it, but simply removing "PRIMITIVE_TYPES.put(String.class,TYPE_STRING);" on line 111 of Util.java might fix the issue entirely by falling back to TYPE_SERIALIZABLE. There could be a small performance impact, but I assume that would be negligible compared to network transmission, etc. The built in serialization for java.lang.String appears to be UTF-8 plus a ~7 byte header, so total transmission size would be roughly the same.
If the guidance is to use manual marshalling, then you could consider deprecating the org.jgroups.Message constructors that take Object obj. That would make it explicit that the user must implement their own marshalling. As a newcomer to JGroups, the general purpose constructor looks like an obvious option. I imagine this could be a common pitfall.
Thanks for taking a look! And thanks for JGroups overall, I think it's great.
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {{case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();}}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months