April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8494) Sharply increased memory consumption (+ ~50 MB) in full profile

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8494?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-8494: ------------------------------ Component/s: (was: Server) > Sharply increased memory consumption (+ ~50 MB) in full profile > --------------------------------------------------------------- > > Key: WFLY-8494 > URL: https://issues.jboss.org/browse/WFLY-8494 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Martyn Taylor > Priority: Blocker > > Memory footprint of full profile after server start jumped 50 megabytes compared to EAP 7.1.0.DR11. Heap dump shows a few huge byte[] arrays referenced by {{io.netty.buffer.PoolChunk}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8494) Sharply increased memory consumption (+ ~50 MB) in full profile

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8494?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-8494: ------------------------------ Labels: (was: eap71_alpha eap71_beta) > Sharply increased memory consumption (+ ~50 MB) in full profile > --------------------------------------------------------------- > > Key: WFLY-8494 > URL: https://issues.jboss.org/browse/WFLY-8494 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Martyn Taylor > Priority: Blocker > > Memory footprint of full profile after server start jumped 50 megabytes compared to EAP 7.1.0.DR11. Heap dump shows a few huge byte[] arrays referenced by {{io.netty.buffer.PoolChunk}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8494) Sharply increased memory consumption (+ ~50 MB) in full profile

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8494?page=com.atlassian.jira.plugin.... ] Jeff Mesnil reassigned WFLY-8494: --------------------------------- Assignee: Jeff Mesnil (was: Martyn Taylor) > Sharply increased memory consumption (+ ~50 MB) in full profile > --------------------------------------------------------------- > > Key: WFLY-8494 > URL: https://issues.jboss.org/browse/WFLY-8494 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > > Memory footprint of full profile after server start jumped 50 megabytes compared to EAP 7.1.0.DR11. Heap dump shows a few huge byte[] arrays referenced by {{io.netty.buffer.PoolChunk}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8493) Upgrade Artemis 1.5.3.jbossorg-004

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8493?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-10082 to WFLY-8493: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8493 (was: JBEAP-10082) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) (was: JMS) > Upgrade Artemis 1.5.3.jbossorg-004 > ---------------------------------- > > Key: WFLY-8493 > URL: https://issues.jboss.org/browse/WFLY-8493 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8492) Cannot cleanly shutdown server disconnected inbound/outbound connections

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8492?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-10081 to WFLY-8492: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8492 (was: JBEAP-10081) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: ActiveMQ) Affects Version/s: (was: 7.1.0.DR13) > Cannot cleanly shutdown server disconnected inbound/outbound connections > ------------------------------------------------------------------------ > > Key: WFLY-8492 > URL: https://issues.jboss.org/browse/WFLY-8492 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > > Customer impact: Server will not be possible to cleanly shutdown and must be killed. No simple management operation command which EAP provides can be used. Similar issue was reported by customers/users in the past and had to be solved by support. > Test Scenario: > * Start server 1 with queues InQueue and OutQueue > * Start server 2 with MDB consuming messages from InQueue and for each message sending 1 new message to OutQueue in XA transaction > * Send messages to InQueue to server 1 > * When MDB is processing messages then cleanly shutdown server 1 > * Cleanly shutdown server 2 with MDB > Result: > Server 2 does not shutdown. > Expected Result: > Server 2 with MDB will shutdown fast ( < 1 min). > Investigation: > Thread dump (attached) on server 2 shows types of waiting threads: > {code} > "Thread-6 (ActiveMQ-client-global-threads-304296137)" #193 daemon prio=5 os_prio=0 tid=0x00007fc63c6d4000 nid=0x924 waiting on condition [0x00007fc5d6e0c000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000fda5f5f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:250) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:356) > - locked <0x00000000fda5f618> (a java.lang.Object) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:383) > at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1173) > at org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112) > at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81) > at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118) > at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:337) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674) > - locked <0x00000000fdb54128> (a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:124) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1298) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:134) > at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:99) > at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:73) > at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:69) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60) > at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135) > at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) > at org.jboss.qa.hornetq.apps.mdb.MdbWithRemoteOutQueueToContaniner1$$$endpoint1.afterDelivery(Unknown Source) > at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:314) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) > at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) > at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > and: > {code} > "Thread-21 (ActiveMQ-client-global-threads-304296137)" #196 daemon prio=5 os_prio=0 tid=0x00007fc62c040800 nid=0x928 waiting on condition [0x00007fc5d6a08000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000fd4bc8a8> (a java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.waitOnLatch(ActiveMQClientProtocolManager.java:136) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.getConnectionWithRetry(ClientSessionFactoryImpl.java:819) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:744) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165) > at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67) > at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207) > at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215) > at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996) > at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > Those threads should be notified of server shutdown and "gracefully" stop do what they're doing. In case 1st thread: > {{at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.waitForFailOver(ChannelImpl.java:250)}} > there is problem in code: > {code} > failoverCondition.await(); > {code} > This should be silently interrupted when component is stopping. > 2nd thread has problem that while() cycle does not finish when component is stopping: > {code} > while (clientProtocolManager.isAlive()) { > ... > try { > if (clientProtocolManager.waitOnLatch(interval)) { > ... > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2613) Upgrade JBoss Remoting to 5.0.0.Beta20

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2613?page=com.atlassian.jira.plugi... ] Martin Simka moved JBEAP-10080 to WFCORE-2613: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2613 (was: JBEAP-10080) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Remoting (was: Remoting) > Upgrade JBoss Remoting to 5.0.0.Beta20 > -------------------------------------- > > Key: WFCORE-2613 > URL: https://issues.jboss.org/browse/WFCORE-2613 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Martin Simka > Assignee: David Lloyd > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1051) Coverity, derefere null return value in KeyStoreCredentialStore.store

by Martin Choma (JIRA)

Martin Choma created ELY-1051: --------------------------------- Summary: Coverity, derefere null return value in KeyStoreCredentialStore.store Key: ELY-1051 URL: https://issues.jboss.org/browse/ELY-1051 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical Coverity found possible null dereference as {{getEntry()}} could return null. https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=12563... {code:java|title=KeyStoreCredentialStore.java} void store(OutputStream outputStream) throws IOException, GeneralSecurityException { ObjectOutputStream oos = new ObjectOutputStream(outputStream); oos.writeInt(VERSION); Enumeration<String> ksAliases = dataKeyStore.aliases(); while(ksAliases.hasMoreElements()) { String alias = ksAliases.nextElement(); KeyStore.Entry entry = dataKeyStore.getEntry(alias, convertParameter(protectionParameter)); if (entry instanceof KeyStore.SecretKeyEntry) { saveSecretKey(alias, oos, (KeyStore.SecretKeyEntry)entry); } else { throw log.unrecognizedEntryType(entry.getClass().getCanonicalName()); } } oos.flush(); oos.close(); } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1050) Coverity, derefere null return value in KeyStoreCredentialStore.saveSecretKey

by Martin Choma (JIRA)

Martin Choma created ELY-1050: --------------------------------- Summary: Coverity, derefere null return value in KeyStoreCredentialStore.saveSecretKey Key: ELY-1050 URL: https://issues.jboss.org/browse/ELY-1050 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical Coverity found possible null dereference, as {{encrypt.getIV()}} could return null in cases when option {{cryptoAlg}} is configured to some algorithm, which does not use IV. https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=12563... {code:java|title=KeyStoreCredentialStore.java} private void saveSecretKey(String ksAlias, ObjectOutputStream oos, KeyStore.SecretKeyEntry entry) throws IOException, GeneralSecurityException { ByteArrayOutputStream entryData = new ByteArrayOutputStream(1024); ObjectOutputStream entryOos = new ObjectOutputStream(entryData); entryOos.writeUTF(ksAlias); writeBytes(entry.getSecretKey().getEncoded(), entryOos); entryOos.flush(); encrypt.init(Cipher.ENCRYPT_MODE, storageSecretKey); int blockSize = encrypt.getBlockSize(); Assert.checkMaximumParameter("cipher block size", 256, blockSize); byte[] padded = pkcs7Pad(entryData.toByteArray(), blockSize); byte[] encrypted = encrypt.doFinal(padded); byte[] iv = encrypt.getIV(); oos.writeInt(SECRET_KEY_ENTRY_TYPE); writeBytes(encrypted, oos); writeBytes(iv, oos); } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1049) Coverity, division by zero in KeyStoreCredentialStore (Elytron)

by Martin Choma (JIRA)

Martin Choma created ELY-1049: --------------------------------- Summary: Coverity, division by zero in KeyStoreCredentialStore (Elytron) Key: ELY-1049 URL: https://issues.jboss.org/browse/ELY-1049 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical Coverity found possible division by zero code. https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=12563... {code:java|title=KeyStoreCredentialStore.java} private byte[] pkcs7Pad(byte[] buffer, int blockSize) { int len = buffer.length; int toFill = blockSize - (len % blockSize); byte[] padded = Arrays.copyOf(buffer, toFill + len); Arrays.fill(padded, len, padded.length, (byte) toFill); return padded; } {code} blockSize could be 0 as {{encrypt.getBlockSize()}} return 0 if used algorithm is not blocked-based. Although default cyptographic algoritm is block-based {{DEFAULT_CRYPTOGRAPHIC_ALGORITHM = "AES/CBC/NoPadding"}} , this is configurable with {{cryptoAlg}} option and thus non-block-based algorithm can be configured. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1048) Coverity, ignoring number of bytes read

by Martin Choma (JIRA)

Martin Choma created ELY-1048: --------------------------------- Summary: Coverity, ignoring number of bytes read Key: ELY-1048 URL: https://issues.jboss.org/browse/ELY-1048 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Coverity found error handling of reading stream is not sufficient. There is no check if number of actual read bytes match number of expected read bytes . {code:java|title=KeyStoreCredentialStore.java} private byte[] readBytes(ObjectInputStream ois) throws IOException { int len = ois.readInt(); byte[] data = new byte[len]; ois.read(data, 0, len); return data; } {code} [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=12563... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 7 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 April 2017