December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1985: -------------------------------- Hmm, by default we have the following headers * Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}} * Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}} * RequestCorrelator for RPCs That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}? Just out of curiosity, I'll change the default to 4 anyway. > Message: make initial size of headers configurable > -------------------------------------------------- > > Key: JGRP-1985 > URL: https://issues.jboss.org/browse/JGRP-1985 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays. > Goal: make the initial headers size configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1985 at 12/24/15 5:27 AM: ---------------------------------------------------------- Hmm, by default we have the following headers * Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}} * Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}} * RequestCorrelator for RPCs That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}, {{FORK}}? Just out of curiosity, I'll change the default to 4 anyway. was (Author: belaban): Hmm, by default we have the following headers * Transport: {{UDP}}, {{TCP}} or {{TCP_NIO2}} * Reliable retransmission and ordering protocol: either {{NAKACK2}} or {{UNICAST3}} * RequestCorrelator for RPCs That's 3 headers most of the time. Which other headers did you see? {{FRAG2}}? Just out of curiosity, I'll change the default to 4 anyway. > Message: make initial size of headers configurable > -------------------------------------------------- > > Key: JGRP-1985 > URL: https://issues.jboss.org/browse/JGRP-1985 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays. > Goal: make the initial headers size configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1999) TCP_NIO2: single selector slows down writes and reads

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1999?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1999. ---------------------------- Resolution: Done > TCP_NIO2: single selector slows down writes and reads > ----------------------------------------------------- > > Key: JGRP-1999 > URL: https://issues.jboss.org/browse/JGRP-1999 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > TCP_NIO2 has a single selector which looks like this: > {noformat} > x=select() > if(read) -> read data from connection x, de-serialize data, pass to thread pool > if(write) -> write data pending on connection x > {noformat} > This means that any operation (read,write) delays other operations. It seems that especially the de-serialization done in reads delays other reads and writes. > A quick test showed that having a reader thread per connection (so that reads don't delay other reads or writes) improved perf from 15'000 reqs/sec to 22'000. > The idea is to have a reader thread in {{NioConnection}} which reads and de-serializes as many messages as possible. When no more messages are ready to be read, it blocks for a max wait time and then terminates unless more messages are ready. This means that idle connections will have no threads allocated. > Investigate: we might possibly also null the pre-allocated buffer when a thread terminates, reducing memory usage even more. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1999) TCP_NIO2: single selector slows down writes and reads

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1999?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1999: -------------------------------- {{OP_READ}} is unregistered on each {{receive()}}, and re-registered when the reader thread is done reading msgs. Quick perf test (UPerf, 4 nodes) showed perf of *~24'000 RPCs/sec/node*, which is equivalent to {{TCP}}. > TCP_NIO2: single selector slows down writes and reads > ----------------------------------------------------- > > Key: JGRP-1999 > URL: https://issues.jboss.org/browse/JGRP-1999 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > TCP_NIO2 has a single selector which looks like this: > {noformat} > x=select() > if(read) -> read data from connection x, de-serialize data, pass to thread pool > if(write) -> write data pending on connection x > {noformat} > This means that any operation (read,write) delays other operations. It seems that especially the de-serialization done in reads delays other reads and writes. > A quick test showed that having a reader thread per connection (so that reads don't delay other reads or writes) improved perf from 15'000 reqs/sec to 22'000. > The idea is to have a reader thread in {{NioConnection}} which reads and de-serializes as many messages as possible. When no more messages are ready to be read, it blocks for a max wait time and then terminates unless more messages are ready. This means that idle connections will have no threads allocated. > Investigate: we might possibly also null the pre-allocated buffer when a thread terminates, reducing memory usage even more. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration updated DROOLS-1015: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1294048 Bugzilla Update: Perform > Wrong MvelConstraint compilation with Unicode class name and the same name property > ----------------------------------------------------------------------------------- > > Key: DROOLS-1015 > URL: https://issues.jboss.org/browse/DROOLS-1015 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > > If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal. > {code:java} > public class I18nPerson implements Serializable { > private 住所住所; // "address" in Japanese > public 住所 get住所() { > return 住所; > } > .... > {code} > {noformat} > when > p : I18nPerson( 住所 != null ) > {noformat} > This constraint is always evaluated to "true". > Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name. > {code:java} > public class Person implements Serializable { > private Address address; > public Address getAddress() { > return address; > } > .... > {code} > {noformat} > when > p : I18nPerson( Address != null ) > {noformat} > Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-1015: -------------------------------------- Git Pull Request: https://github.com/droolsjbpm/drools/pull/592 > Wrong MvelConstraint compilation with Unicode class name and the same name property > ----------------------------------------------------------------------------------- > > Key: DROOLS-1015 > URL: https://issues.jboss.org/browse/DROOLS-1015 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > > If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal. > {code:java} > public class I18nPerson implements Serializable { > private 住所住所; // "address" in Japanese > public 住所 get住所() { > return 住所; > } > .... > {code} > {noformat} > when > p : I18nPerson( 住所 != null ) > {noformat} > This constraint is always evaluated to "true". > Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name. > {code:java} > public class Person implements Serializable { > private Address address; > public Address getAddress() { > return address; > } > .... > {code} > {noformat} > when > p : I18nPerson( Address != null ) > {noformat} > Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by Toshiya Kobayashi (JIRA)

Toshiya Kobayashi created DROOLS-1015: ----------------------------------------- Summary: Wrong MvelConstraint compilation with Unicode class name and the same name property Key: DROOLS-1015 URL: https://issues.jboss.org/browse/DROOLS-1015 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Reporter: Toshiya Kobayashi Assignee: Mario Fusco If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal. {code:java} public class I18nPerson implements Serializable { private 住所住所; // "address" in Japanese public 住所 get住所() { return 住所; } .... {code} {noformat} when p : I18nPerson( 住所 != null ) {noformat} This constraint is always evaluated to "true". Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name. {code:java} public class Person implements Serializable { private Address address; public Address getAddress() { return address; } .... {code} {noformat} when p : I18nPerson( Address != null ) {noformat} Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3660) allow easy creation of executable war

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3660?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-3660. ------------------------------- Resolution: Won't Do I do think [WildFly Swarm|http://wildfly-swarm.io/] does solve this issue. If the requester feels this is not the case please reopen. > allow easy creation of executable war > ------------------------------------- > > Key: WFLY-3660 > URL: https://issues.jboss.org/browse/WFLY-3660 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Reporter: jieryn jieryn > Assignee: James Perkins > Priority: Minor > > Other popular Servlet Containers and Application Servers support the building of an executable war bundle, via Apache Maven. This will allow you to easily bundle your WAR/EAR into an executable war which will unpack and launch the WAR/EAR, via java -jar myapp.war. > http://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/exec-war-m... > http://rmannibucau.wordpress.com/2014/03/11/executable-jar-with-tomee-and... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1012: ------------------------------------------------- Alessandro Lazarotti <alazarot(a)redhat.com> changed the Status of [bug 1293965|https://bugzilla.redhat.com/show_bug.cgi?id=1293965] from NEW to ASSIGNED > kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry > ------------------------------------------------------------------------------------- > > Key: DROOLS-1012 > URL: https://issues.jboss.org/browse/DROOLS-1012 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.x > > Attachments: brms-fuse-integration-master.tgz > > > kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled. > The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse: > features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features > features:install brms-integration-bundle -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5910) Update Resteasy from 3.013.Final to 3.0.14.Final

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-5910?page=com.atlassian.jira.plugin.... ] Frank Langelage closed WFLY-5910. --------------------------------- Resolution: Duplicate Issue duplicate of https://issues.jboss.org/browse/WFLY-5837. > Update Resteasy from 3.013.Final to 3.0.14.Final > ------------------------------------------------ > > Key: WFLY-5910 > URL: https://issues.jboss.org/browse/WFLY-5910 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Affects Versions: 10.0.0.CR5 > Reporter: Frank Langelage > Assignee: Stuart Douglas > Fix For: 10.0.0.Final > > > Update Resteasy to latest version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015