November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-1989: ----------------------------------- Now it really just passes the buffer into the queue, but in the past (looking into git history before the NIO stuff) you've copied the buffer there: {code:java} public void send(byte[] data, int offset, int length) throws Exception { if (sender != null) { // we need to copy the byte[] buffer here because the original buffer might get changed meanwhile byte[] tmp = new byte[length]; System.arraycopy(data, offset, tmp, 0, length); sender.addToQueue(tmp); } else _send(data, offset, length, true, true); } {code} So the current state when you allocate the buffer anew is not that worse after all (besides allocating more than you need), because it just moved the invocation to bundler. > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1989: -------------------------------- TCPConnection.send() only makes a copy if you pass a direct ByteBuffer to it, otherwise it doesn't. Are you referring to code further up the stack? > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-1989: ----------------------------------- The data were copied before sending even before, in {{TcpConnection.send}} - will you eliminate this copy, too? > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5744) Improve readability of missing dependency logs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5744?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-5744: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1283294 Bugzilla Update: Perform > Improve readability of missing dependency logs > ---------------------------------------------- > > Key: WFLY-5744 > URL: https://issues.jboss.org/browse/WFLY-5744 > Project: WildFly > Issue Type: Feature Request > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Dennis Reed > > When there is a problem with a failed deployment due to missing dependencies it is difficult to figure out what the problem is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5744) Improve readability of missing dependency logs

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created WFLY-5744: ---------------------------------------------- Summary: Improve readability of missing dependency logs Key: WFLY-5744 URL: https://issues.jboss.org/browse/WFLY-5744 Project: WildFly Issue Type: Feature Request Reporter: Bartosz Spyrko-Śmietanko Assignee: Dennis Reed When there is a problem with a failed deployment due to missing dependencies it is difficult to figure out what the problem is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5743) Module org.javassist not excluded when persistence.xml contains property <property name="jboss.as.jpa.providerModule" value="application" />

by Juraj Staník (JIRA)

Juraj Staník created WFLY-5743: ---------------------------------- Summary: Module org.javassist not excluded when persistence.xml contains property <property name="jboss.as.jpa.providerModule" value="application" /> Key: WFLY-5743 URL: https://issues.jboss.org/browse/WFLY-5743 Project: WildFly Issue Type: Bug Components: Class Loading Affects Versions: 9.0.2.Final Environment: OS: Windows 7 JVM: jdk1.7.0_79, WF: wildfly-9.0.2.Final DB: h2 Reporter: Juraj Staník Assignee: David Lloyd Attachments: class-loading-problem.zip Excluding the module 'org.javassit' in the jboss-deployment-structure.xml does not work correctly for all modules in EAR when shipping custom version of Hibernate and Javassist and setting property <property name="jboss.as.jpa.providerModule" value="application" /> in the persistence.xml. In case of the following EAR structure: {noformat} EAR |`-- lib | |`-- javassist-3.20.0-GA.jar | `-- <hibernate 4.2.19 jars> |`-- META-INF | |`-- jboss-deployment-structure.xml | `-- application.xml |`-- EJB-JAR | `-- META-INF | `-- persistence.xml `-- WAR {noformat} and the content of the jboss-deployment-structure.xml {code:title=jboss-deployment-structure.xml|xml} <?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1"> <ear-subdeployments-isolated>false</ear-subdeployments-isolated> <deployment> <exclusions> <module name="org.hibernate" /> <module name="org.javassist" /> </exclusions> </deployment> </jboss-deployment-structure> {code} and persistence.xml {code:title=persistence.xml|xml} <?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" version="2.1"> <persistence-unit name="cce-example" transaction-type="JTA"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <jta-data-source>jdbc/CCE_DS</jta-data-source> <properties> <property name="jboss.as.jpa.providerModule" value="application" /> </properties> </persistence-unit> </persistence> {code} The module EJB-JAR loads javassist classes not from the bundled {{EAR/lib/javassist-3.20.0-GA.jar}} but from {{<WF>/modules/system/layers/base/org/javassist/main/javassist-3.18.1-GA.jar}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1166) CompositeTransformer does not transform addresses

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1166?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1166: ------------------------------- Description: If /some=where has a child redirection for the child=* child resource to new-child=*, then {code} { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } {code} gets correctly transformed to {code} { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } {code} But if wrapped in a composite, e.g.: {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} the redirection does not happen in the transformed composite, so we have the original {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} rather than the expected {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } ] } {code} was: If /some=where has a child redirection for the child=* child resource to new-child=*, then {code} { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } {code} gets correctly transformed to {code} { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } {code} But if wrapped in a transformer, e.g.: {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} the redirection does not happen in the transformed composite, so we have the original {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("child" => "*") ] } ] } {code} rather than the expected {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "add", "address" => [ ("some" => "where"), ("new-child" => "*") ] } ] } {code} > CompositeTransformer does not transform addresses > ------------------------------------------------- > > Key: WFCORE-1166 > URL: https://issues.jboss.org/browse/WFCORE-1166 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.3.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > > If /some=where has a child redirection for the child=* child resource to new-child=*, then > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > {code} > gets correctly transformed to > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > {code} > But if wrapped in a composite, e.g.: > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > the redirection does not happen in the transformed composite, so we have the original > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > rather than the expected > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > ] > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1166) CompositeTransformer does not transform addresses

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1166?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-2030 to WFCORE-1166: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1166 (was: JBEAP-2030) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Domain Management (was: Domain Management) Target Release: (was: 7.0.0.GA) Affects Version/s: 2.0.3.Final (was: 7.0.0.ER1) > CompositeTransformer does not transform addresses > ------------------------------------------------- > > Key: WFCORE-1166 > URL: https://issues.jboss.org/browse/WFCORE-1166 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.3.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > > If /some=where has a child redirection for the child=* child resource to new-child=*, then > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > {code} > gets correctly transformed to > {code} > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > {code} > But if wrapped in a transformer, e.g.: > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > the redirection does not happen in the transformed composite, so we have the original > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("child" => "*") > ] > } > ] > } > {code} > rather than the expected > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [ > ("some" => "where"), > ("new-child" => "*") > ] > } > ] > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-378) Release WildFly Elytron 1.1.0.Beta2

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-378: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta2 Key: ELY-378 URL: https://issues.jboss.org/browse/ELY-378 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-35) Notification of outcome from authentication mechanism through to realm.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-35?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse reassigned ELY-35: ----------------------------------- Assignee: David Lloyd > Notification of outcome from authentication mechanism through to realm. > ----------------------------------------------------------------------- > > Key: ELY-35 > URL: https://issues.jboss.org/browse/ELY-35 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta2 > > > Realm implementations may want to track successful / unsuccessful calls. > Note: There may be a better way to consider this so do not take the title too literally. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015