[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated JGRP-1752:
------------------------------
Priority: Major (was: Minor)
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1752:
-----------------------------------
Recommended fix is to allow overwriting null header. That would fix the retransmissions, although first error may still occur in the log.
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1752?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated JGRP-1752:
------------------------------
Affects Version/s: 3.4.1
> Concurrent message headers modification causes that message is never sent
> -------------------------------------------------------------------------
>
> Key: JGRP-1752
> URL: https://issues.jboss.org/browse/JGRP-1752
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
>
> Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
> This happens for example when the stable message triggers retransmission while the message has been sent right now.
> This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (JGRP-1752) Concurrent message headers modification causes that message is never sent
by Radim Vansa (JIRA)
Radim Vansa created JGRP-1752:
---------------------------------
Summary: Concurrent message headers modification causes that message is never sent
Key: JGRP-1752
URL: https://issues.jboss.org/browse/JGRP-1752
Project: JGroups
Issue Type: Bug
Reporter: Radim Vansa
Assignee: Bela Ban
Priority: Minor
Under some circumstances the TP protocol may try to add the TP header to message twice concurrently.
This happens for example when the stable message triggers retransmission while the message has been sent right now.
This may result in ArrayOutOfBoundException in Headers._putHeader and/or subsequent NullPointerException in Headers.size(). The retransmission attempt always fails, the message is never delivered. Moreover, keeping this (and possibly following) messages in the transmission table can lead to OOME.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Michael Kozak (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Michael Kozak edited comment on WFLY-2593 at 12/3/13 7:13 AM:
--------------------------------------------------------------
I didn't notice the fix is so simple.
I see scopedPUName is not used in your snippet so puService is not need either since getPersistenceUnitService does only a map lookup. I also noticed getQueryNames() handles the case when there are no statistics very well therefore I propose a simplified version:
{code}
private boolean hasQuery(final PathElement element) {
return getQueryNames().contains(element.getValue());
}
{code}
Correct me if I'm wrong.
Is there any chance the fix will land in EAP 6.2 ?
was (Author: lklm):
I didn't notice the fix is so simple.
I see scopedPUName is not used in your snippet so puService is not need either since getPersistenceUnitService does only a map lookup. I also noticed getQueryNames() handles the case when there are no statistics very well therefore I propose a simplified version:
{code}
private boolean hasQuery(final PathElement element) {
return getQueryNames().contains(element.getValue());
}
{code}
Correct me if I'm wrong.
Is there any chance the fix will land is EAP 6.2 ?
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
> Key: WFLY-2593
> URL: https://issues.jboss.org/browse/WFLY-2593
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: No Release
> Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
> Reporter: Michael Kozak
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: No Release
>
> Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA.
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Michael Kozak (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Michael Kozak commented on WFLY-2593:
-------------------------------------
I didn't notice the fix is so simple.
I see scopedPUName is not used in your snippet so puService is not need either since getPersistenceUnitService does only a map lookup. I also noticed getQueryNames() handles the case when there are no statistics very well therefore I propose a simplified version:
{code}
private boolean hasQuery(final PathElement element) {
return getQueryNames().contains(element.getValue());
}
{code}
Correct me if I'm wrong.
Is there any chance the fix will land is EAP 6.2 ?
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
> Key: WFLY-2593
> URL: https://issues.jboss.org/browse/WFLY-2593
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: No Release
> Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
> Reporter: Michael Kozak
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: No Release
>
> Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA.
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-1533:
------------------------------------
Actually I was wrong the stacktrace will only show if the logging level for Weld is set to DEBUG. A more concise message is logged with WARN level.
> UT015005: Error invoking method requestDestroyed on listener class
> -------------------------------------------------------------------
>
> Key: WFLY-1533
> URL: https://issues.jboss.org/browse/WFLY-1533
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
> Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip
>
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (WFLY-1533) UT015005: Error invoking method requestDestroyed on listener class
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.... ]
Martin Kouba reopened WFLY-1533:
--------------------------------
> UT015005: Error invoking method requestDestroyed on listener class
> -------------------------------------------------------------------
>
> Key: WFLY-1533
> URL: https://issues.jboss.org/browse/WFLY-1533
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
> Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip
>
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/SECURITY-770?page=com.atlassian.jira.plug... ]
Ivo Studensky commented on SECURITY-770:
----------------------------------------
Thanks.
> Support external password for keystore of PicketBoxVault implementation
> -----------------------------------------------------------------------
>
> Key: SECURITY-770
> URL: https://issues.jboss.org/browse/SECURITY-770
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Ivo Studensky
> Assignee: Peter Skopek
> Fix For: PicketBox_4_0_20.Final
>
> Attachments: SECURITY-770_with_testcase_2.patch
>
>
> At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months