November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3435) jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3435?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3435: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1007015|https://bugzilla.redhat.com/show_bug.cgi?id=1007015] from ON_QA to VERIFIED > jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-3435 > URL: https://issues.jboss.org/browse/WFLY-3435 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Alpha1 > > > Description of problem: > In org.infinispan.loaders.decorators.AsyncStoreConfig, the default flushLockTimeout is set to 5000. However, the default in the JBoss Infinispan schema ($JBOSS_HOME/docs/schema/jboss-as-infinispan_1_X.xsd) is set to 1. Because of this, if the thread-pool-size for write-behind is increased, then it is likely that one of the threads will not be able to obtain the state map lock within the 1 millisecond time provided by the schema default. This results in the following error: > ERROR o.i.loaders.decorators.AsyncStore.run - ISPN000051: Unexpected error > org.infinispan.CacheException: Unable to acquire lock on update map > at org.infinispan.loaders.decorators.AsyncStore.acquireLock(AsyncStore.java:293) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore.access$900(AsyncStore.java:86) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.innerRun(AsyncStore.java:336) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.run(AsyncStore.java:312) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_31] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_31] > at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_31] > Version-Release number of selected component (if applicable): > Infinispan version 5.1.8 > How reproducible: > Code inspection > Steps to Reproduce: > 1. Check the default value for flush-lock-timeout in $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd > 2. Check the default value for flushLockTimeout in the org.infinispan.loaders.decorators.AsyncStoreConfig class > 3. Note the disparity > Actual results: > Default in schema is 1 > Expected results: > Default in schema is 5000 > Additional info: -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-245: ------------------------------------------------ Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1160541|https://bugzilla.redhat.com/show_bug.cgi?id=1160541] from ON_QA to VERIFIED > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1904?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1904: --------------------------- Description: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) * It should also be possible to trigger the sending programmatically, or via JMX was: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) * It should be possible to trigger the sending programmatically, or via JMX > NAKACK2: retransmit the last-message-missing sooner > --------------------------------------------------- > > Key: JGRP-1904 > URL: https://issues.jboss.org/browse/JGRP-1904 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. > Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. > When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. > So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. > We therefore need a quicker way to detect and retransmit missing messages. > h5. Solution > * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. > * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission > * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > * It should also be possible to trigger the sending programmatically, or via JMX -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1904?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1904: --------------------------- Description: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) * It should be possible to trigger the sending programmatically, or via JMX was: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > NAKACK2: retransmit the last-message-missing sooner > --------------------------------------------------- > > Key: JGRP-1904 > URL: https://issues.jboss.org/browse/JGRP-1904 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. > Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. > When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. > So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. > We therefore need a quicker way to detect and retransmit missing messages. > h5. Solution > * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. > * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission > * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > * It should be possible to trigger the sending programmatically, or via JMX -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner

by Bela Ban (JIRA)

Bela Ban created JGRP-1904: ------------------------------ Summary: NAKACK2: retransmit the last-message-missing sooner Key: JGRP-1904 URL: https://issues.jboss.org/browse/JGRP-1904 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.1 When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBVFS-199) RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/JBVFS-199?page=com.atlassian.jira.plugin.... ] Enrique González Martínez updated JBVFS-199: -------------------------------------------- Fix Version/s: 3.5.0.Alpha1 > RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb > ------------------------------------------------------------------------------------------------------------------ > > Key: JBVFS-199 > URL: https://issues.jboss.org/browse/JBVFS-199 > Project: JBoss VFS > Issue Type: Bug > Affects Versions: 3.2.5.Final, 3.5.0.Alpha1 > Environment: Windows 64 bits > JDK 1.7.0_71 > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Fix For: 3.2.8.Final, 3.5.0.Alpha1 > > > In Wildfly, during jsp compilation the lookup function uses the Classloader::getResourceAsStream that relies on VFSResourceLoader for opening an InputStream. This function is working different due to windows file system (not case sensitive). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBVFS-199) RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/JBVFS-199?page=com.atlassian.jira.plugin.... ] Enrique González Martínez resolved JBVFS-199. --------------------------------------------- Fix Version/s: 3.2.8.Final Resolution: Done > RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb > ------------------------------------------------------------------------------------------------------------------ > > Key: JBVFS-199 > URL: https://issues.jboss.org/browse/JBVFS-199 > Project: JBoss VFS > Issue Type: Bug > Affects Versions: 3.2.5.Final, 3.5.0.Alpha1 > Environment: Windows 64 bits > JDK 1.7.0_71 > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Fix For: 3.2.8.Final > > > In Wildfly, during jsp compilation the lookup function uses the Classloader::getResourceAsStream that relies on VFSResourceLoader for opening an InputStream. This function is working different due to windows file system (not case sensitive). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-271: ------------------------------------------------ Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1162982|https://bugzilla.redhat.com/show_bug.cgi?id=1162982] from ON_QA to VERIFIED > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.... ] SBS JIRA Integration updated WFLY-4125: --------------------------------------- Forum Reference: https://developer.jboss.org/message/910596#910596 > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments.

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin... ] Bartosz Baranowski updated WFCORE-129: -------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/334, https://github.com/wildfly/wildfly/pull/6961 (was: https://github.com/wildfly/wildfly-core/pull/334) > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha14 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 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 2014