[JBoss JIRA] (WFLY-3974) Move 'Channel end notification received, closing channel' to DEBUG
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3974?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3974:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1153281|https://bugzilla.redhat.com/show_bug.cgi?id=1153281] from ON_QA to VERIFIED
> Move 'Channel end notification received, closing channel' to DEBUG
> ------------------------------------------------------------------
>
> Key: WFLY-3974
> URL: https://issues.jboss.org/browse/WFLY-3974
> Project: WildFly
> Issue Type: Enhancement
> Components: Naming
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When a remote jms queue is located the following is seen:
> 2014-09-25 16:48:29,327 INFO [org.jboss.as.naming] (Remoting "jeev6dev01_200" task-1) JBAS011806: Notification de fin de canal reçue, fermeture du canal Channel ID 0cb79bd5 (inbound) of Remoting connection 53a1933a to /10.23.132.245:57733
> This is due to org.jboss.as.naming.NamingLogger where the following is used:
> @LogMessage(level=Logger.Level.INFO)
> @Message(id=11806, value="Channel end notification received, closing channel %s")
> public abstract void closingChannelOnChannelEnd(Channel paramChannel);
> Changin this to
> @LogMessage(level=Logger.Level.DEBUG)
> Would ensure that an INFO log event is not seen every time a jms message is sent to the server.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-451) Filter Apache CXF
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-451:
----------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1166502|https://bugzilla.redhat.com/show_bug.cgi?id=1166502] from ON_QA to VERIFIED
> Filter Apache CXF
> -----------------
>
> Key: WFLY-451
> URL: https://issues.jboss.org/browse/WFLY-451
> Project: WildFly
> Issue Type: Task
> Components: Web Services
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Fix For: 8.0.0.Alpha1
>
>
> Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-655) Debug: Line after "THEN" ignored
by Marc Dzaebel (JIRA)
[ https://issues.jboss.org/browse/DROOLS-655?page=com.atlassian.jira.plugin... ]
Marc Dzaebel updated DROOLS-655:
--------------------------------
Description:
If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view.
{code}
rule ""
when
then int i=1;
System.out.println( i); // breakpoint set here
end
{code}
Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines. However, the above rule works.
was:
If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view.
{code}
rule ""
when
then int i=1;
System.out.println( i); // breakpoint set here
end
{code}
Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines.
> Debug: Line after "THEN" ignored
> --------------------------------
>
> Key: DROOLS-655
> URL: https://issues.jboss.org/browse/DROOLS-655
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.CR2
> Environment: All (Eclipse Debug)
> Reporter: Marc Dzaebel
> Assignee: Mark Proctor
> Priority: Minor
>
> If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view.
> {code}
> rule ""
> when
> then int i=1;
> System.out.println( i); // breakpoint set here
> end
> {code}
> Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines. However, the above rule works.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-655) Debug: Line after "THEN" ignored
by Marc Dzaebel (JIRA)
Marc Dzaebel created DROOLS-655:
-----------------------------------
Summary: Debug: Line after "THEN" ignored
Key: DROOLS-655
URL: https://issues.jboss.org/browse/DROOLS-655
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.CR2
Environment: All (Eclipse Debug)
Reporter: Marc Dzaebel
Assignee: Mark Proctor
Priority: Minor
If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view.
{code}
rule ""
when
then int i=1;
System.out.println( i); // breakpoint set here
end
{code}
Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[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)
9 years, 7 months
[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)
9 years, 7 months
[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)
9 years, 7 months
[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)
9 years, 7 months