November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4407) Upgrade wildfly-core to 1.0.0.Beta1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4407?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4407: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1196686|https://bugzilla.redhat.com/show_bug.cgi?id=1196686] from ASSIGNED to POST > Upgrade wildfly-core to 1.0.0.Beta1 > ----------------------------------- > > Key: WFLY-4407 > URL: https://issues.jboss.org/browse/WFLY-4407 > Project: WildFly > Issue Type: Component Upgrade > Affects Versions: 9.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Jason Greene > Priority: Major > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4404) View does not inherit 'default' methods from interfaces( JDK8 )

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4404?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4404: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1196686|https://bugzilla.redhat.com/show_bug.cgi?id=1196686] from ASSIGNED to POST > View does not inherit 'default' methods from interfaces( JDK8 ) > --------------------------------------------------------------- > > Key: WFLY-4404 > URL: https://issues.jboss.org/browse/WFLY-4404 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Priority: Major > Fix For: 10.0.0.Final > > > View and View service do not inherit JDK8 'default' methods from interfaces. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1094) ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-1094: ----------------------------------------- Summary: ConfigurationChangeResourceRemoveHandler makes its changes in the constructor not in execute Key: WFCORE-1094 URL: https://issues.jboss.org/browse/WFCORE-1094 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.0.0.Final Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet Priority: Major Fix For: 3.0.0.Alpha1 ConfigurationChangeResourceRemoveHandler is calling ConfigurationChangesCollector.deactivate() in its constructor. So deactivate gets called at early boot when the ConfigurationChangeResourceDefinition class gets loaded and the maxHistory is still 0, but never thereafter. A reload won't cause it to get called again either, as ConfigurationChangeResourceDefinition is only constructed when the static INSTANCE member is initialized. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-254) javassist.bytecode.analysis.Analyzer causes errors for valid Java (byte) code

by Maximilian Scherr (JIRA)

Maximilian Scherr created JASSIST-254: ----------------------------------------- Summary: javassist.bytecode.analysis.Analyzer causes errors for valid Java (byte) code Key: JASSIST-254 URL: https://issues.jboss.org/browse/JASSIST-254 Project: Javassist Issue Type: Bug Affects Versions: 3.20.0-GA Reporter: Maximilian Scherr Assignee: Shigeru Chiba Priority: Optional The data-flow analysis of javassist.bytecode.analysis.Analyzer reports errors for valid bytecode. The issue can be traced back to the components desire to be accurate with interface assignability (whereas the JVM verifier seems to ignore this or is more lenient, cf. JVM specification 4.10.1.2. Verification Type System). Assuming an Object typed variable is initialized with a class implementing two interfaces and we want to use this variable in methods for these two interfaces we can for both of them do an intersection cast (IntA & IntB) for its argument. This is valid Java, and in bytecode this will turn into a serious of casts to make sure the intersection holds. It does not seem to matter to the JVM bytecode verifier in which order, but for Analyzer the last cast will determine the type of the operand/argument. So sometimes this will lead to a wrong argument type. The example below should clarify what I mean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5418) start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5418?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5418: ----------------------------------------------- Ondřej Kalman <okalman(a)redhat.com> changed the Status of [bug 1266913|https://bugzilla.redhat.com/show_bug.cgi?id=1266913] from ON_QA to ASSIGNED > start-delivery/stop-delivery operations descriptions are missing from MDB deployment in domain mode > --------------------------------------------------------------------------------------------------- > > Key: WFLY-5418 > URL: https://issues.jboss.org/browse/WFLY-5418 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.4.3 > Reporter: Tom Ross > Assignee: Jeff Mesnil > Priority: Major > Fix For: 10.0.0.CR4 > > > It is possible to start/stop delivery of messages to MDB in standalone mode using operations > start-delivery() and stop-delivery() on MDB deployment. > Those operations are available in domain mode but their descriptions are missing (preventing CLI autocompletion to work as expected). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-151) HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/HIBERNATE-151?page=com.atlassian.jira.plu... ] Hynek Švábek deleted HIBERNATE-151: ----------------------------------- > HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4 > ------------------------------------------------------------------------------------------- > > Key: HIBERNATE-151 > URL: https://issues.jboss.org/browse/HIBERNATE-151 > Project: Hibernate Integration > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Scott Marlow > Priority: Major > > Hi, > I have some problems with performance tests. HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4 > I have performance tests for HSearch 4.6 (EAP6.4.x) and I migrated them for HSearch 5.5 (EAP7). > Now I have worse results for settings with directory-based indexManager. Reports are in attachments. > I run tests on same machine. > NOTICE: > With Near-real-time index manager is HSearch 5.5 faster than old one. This is ok :). > I observed some changes with number of index managers (see reports in the end) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-151) HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/HIBERNATE-151?page=com.atlassian.jira.plu... ] Hynek Švábek moved WFLY-5622 to HIBERNATE-151: ---------------------------------------------- Project: Hibernate Integration (was: WildFly) Key: HIBERNATE-151 (was: WFLY-5622) Workflow: classic default workflow (was: GIT Pull Request workflow ) Component/s: (was: JPA / Hibernate) > HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4 > ------------------------------------------------------------------------------------------- > > Key: HIBERNATE-151 > URL: https://issues.jboss.org/browse/HIBERNATE-151 > Project: Hibernate Integration > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Scott Marlow > Priority: Major > > Hi, > I have some problems with performance tests. HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4 > I have performance tests for HSearch 4.6 (EAP6.4.x) and I migrated them for HSearch 5.5 (EAP7). > Now I have worse results for settings with directory-based indexManager. Reports are in attachments. > I run tests on same machine. > NOTICE: > With Near-real-time index manager is HSearch 5.5 faster than old one. This is ok :). > I observed some changes with number of index managers (see reports in the end) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5622) HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4

by Hynek Švábek (JIRA)

Hynek Švábek created WFLY-5622: ---------------------------------- Summary: HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4 Key: WFLY-5622 URL: https://issues.jboss.org/browse/WFLY-5622 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Hynek Švábek Assignee: Scott Marlow Priority: Major Hi, I have some problems with performance tests. HSearch with directory-based indexManager is in EAP7DR12/13 slower than HSearch in EAP6.4.4 I have performance tests for HSearch 4.6 (EAP6.4.x) and I migrated them for HSearch 5.5 (EAP7). Now I have worse results for settings with directory-based indexManager. Reports are in attachments. I run tests on same machine. NOTICE: With Near-real-time index manager is HSearch 5.5 faster than old one. This is ok :). I observed some changes with number of index managers (see reports in the end) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4570) wildfly-init-debian.sh fails on Ubuntu 15.04

by Karel Černohorsk (JIRA)

[ https://issues.jboss.org/browse/WFLY-4570?page=com.atlassian.jira.plugin.... ] Karel Černohorsk commented on WFLY-4570: ---------------------------------------- [~gesker]: The service starts fine with symbolic link to the configuration file (e.g. /etc/default/wildfly -> /opt/wildfly/bin/init.d/wildfly.conf). But for the script (e.g. /etc/init.d/wildfly -> /opt/wildfly/bin/init.d/wildfly-init-debian.sh) it needs a hard link (at least, or a plain copy). With symlink it fails to see functions included by `. /lib/lsb/init-functions`. [~guirald]: There's no need to rewrite the script, the functions `pidofproc` and `log_*` are available on Ubuntu and included from `. /lib/lsb/init-functions`. The issue stems probably from some user / env issue (root vs. wildfly) by symlinking the script. And, such a simple replacement of pidofproc by pidof (as in your script version) is not quite reliable / complete, due to status codes mismatch. > wildfly-init-debian.sh fails on Ubuntu 15.04 > -------------------------------------------- > > Key: WFLY-4570 > URL: https://issues.jboss.org/browse/WFLY-4570 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.0.Beta2, 9.0.0.CR1 > Environment: Ubuntu 15.04, Oracle JDK_1.8.0_45-b14 > Reporter: Dennis Gesker > Fix For: Awaiting Volunteers > > > Init script "wildfly-init-debian.sh" fails on Ubuntu 15.04 but standalone.sh works fine. Env is jdk_1.8.0_45-b14 and wildfly_9.0.0.Beta2. The error returned is: > Failed to start wildfly.service: Unit wildfly.service failed to load: No such file or directory. > Had no issue with the above script on Ubuntu 14.04 so guessing a change in Ubuntu ("Upstart" Maybe?) But, I'm far from an upstart or bash expert. bash -x seems to at least create the pid. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1276) Prefill race condition in flush

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1276?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1276: ------------------------------------------------ Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1231658|https://bugzilla.redhat.com/show_bug.cgi?id=1231658] from ON_QA to VERIFIED > Prefill race condition in flush > ------------------------------- > > Key: JBJCA-1276 > URL: https://issues.jboss.org/browse/JBJCA-1276 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.0.31.Final, 1.1.9.Final > Reporter: Takayoshi Kimura > Assignee: Jesper Pedersen > Priority: Major > Fix For: 1.0.33.Final > > Attachments: server.log > > > There is a race condition between AbstractPool and SemaphoreArrayListManagedConnectionPool. > https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/... > https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/... > AbstractPool flushes the mcp, mcp invokes PoolFiller which works in a separate thread. However AbstractPool is going to unregister the empty mcp and this mcp is no longer used. Then the dead mcp is prefilled in a separate thread by PoolFiller. > At next getConnection(), the mcp is re-initialized and prefilled. > I've attached logs, prefill enabled and min-size is 10. Boot server, invoke flush-all-connection-in-pool, getConnection() then killed. The prefill is done 3 times where it should be twice. > {noformat} > 16:26:04,254 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) ExampleDS: flush(true) > 16:26:04,255 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) Destroying flushed connection org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1d298ed8[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@4ae26a1b connection handles=0 lastUse=1434353148384 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@379ba3b3[connectionListener=1d298ed8 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null] > (repeat 10 times) > 16:02:20,666 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 7) Shutdown - Pool: ExampleDS MCP: 2f5a2102 > 16:02:20,666 TRACE [org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory] (JCA PoolFiller) Using properties: {user=sa, password=--hidden--} > 16:02:20,666 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (management-handler-thread - 7) Unregister pool: SemaphoreArrayListManagedConnectionPool@2f5a2102[pool=ExampleDS] > 16:26:04,259 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@34f0bb27[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@288f1898 connection handles=0 lastUse=1434353164259 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@4a97b7f5[connectionListener=34f0bb27 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null] > (repeat 10 times) > 16:26:11,342 TRACE [org.jboss.jca.core.connectionmanager.TxConnectionManager] (http-/127.0.0.1:8080-1) getManagedConnection interleaving=false , tx=null > 16:26:11,343 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (http-/127.0.0.1:8080-1) Register pool: SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] (interval=1800000) > 16:26:11,344 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1c706b4d[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@18949ad1 connection handles=0 lastUse=1434353171343 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] xaResource=LocalXAResourceImpl@44401bf2[connectionListener=1c706b4d connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null] > (repeat 10 times) > {noformat} > In 1.0.31.Final: > > if (mcp.isEmpty()) > > clearMcpPools.add(mcp); > In 1.2 branch it looks like already fixed within commit 956af09c8494d4187db24a253e7e37b5ba5d9779 for JBJCA-1135: > > if (mcp.isEmpty() && !isPrefill() && size > 1) > > clearMcpPools.add(mcp); > We probably need to backport "!isPrefill()" to the 1.0/1.1 branch. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 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