[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
[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
[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
[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
[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
[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
[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