[JBoss JIRA] (JGRP-1659) deadlock in MFC with default configuration
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1659?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1659.
----------------------------
Resolution: Done
Added a warning when frag_size >= max_credits * min_threshold
> deadlock in MFC with default configuration
> ------------------------------------------
>
> Key: JGRP-1659
> URL: https://issues.jboss.org/browse/JGRP-1659
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.7
> Reporter: Mircea Markus
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: expiration-test.zip
>
>
> MFC.down does the following:
> {code:java}
> credits.decrement(length, block_time); //A
> if(needToSendCreditRequest()) //B
> sendCreditRequest(tuple.getVal1(), Math.min(max_credits)
> {code}
> A blocks forever even if the MFC.max_block_time is configured:
> {code:xml}
> <MFC max_credits="200k" min_threshold="0.20" max_block_time="1"/>
> {code}
> This happens at the same time on the whole cluster. B never gets invoked, so both wake up conditions( credits received or timeout) for credits.decrement are never satisfied resulting in the whole cluster to freeze.
--
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
12 years, 9 months
[JBoss JIRA] (JBWEB-276) Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-276?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWEB-276:
-----------------------------------------------
Rémy Maucherat <rmaucher(a)redhat.com> made a comment on [bug 985191|https://bugzilla.redhat.com/show_bug.cgi?id=985191]
I agree it is obviously the intended design in that case, but I don't know how to differentiate between the two situations since the executor is a black box. So using a dedicated subcategory for these few messages would allow filtering them out, but they should remain at error level.
> Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged
> ----------------------------------------------------------------------------------------
>
> Key: JBWEB-276
> URL: https://issues.jboss.org/browse/JBWEB-276
> Project: JBoss Web
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.2.0.Beta1
> Reporter: James Livingston
> Assignee: Remy Maucherat
> Attachments: JBWEB-276-1.patch
>
>
> When a finite-queue thread pool is used to process web requests, the queue being full can either block or drop the request. If you use a pool which drops requests, a RejectedExecutionException is thrown.
> Currently JIoEndpoint catches that exception the same as other ones such as being unable to create threads. When using a non-blocking pool, the task being rejected is not a critical error like other exceptions so should not be logged at ERROR level.
> Under excessive load, these exception will be continuously generated as requests are dropped, which cases a large amount of logging. Setting it to DEBUG level would stop that, but it would hide the potentially useful messages by default.
--
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
12 years, 9 months
[JBoss JIRA] (JGRP-1662) Remove flow control and fragmentation if run on TCP transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1662?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1662.
----------------------------
Resolution: Won't Fix
Leaving MFC and FRAG2 in actually led to better performance than removing them. So I won't do this.
> Remove flow control and fragmentation if run on TCP transport
> -------------------------------------------------------------
>
> Key: JGRP-1662
> URL: https://issues.jboss.org/browse/JGRP-1662
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3.4, 3.4
>
>
> When run with a TCP transport, we don't need MFC and FRAG(2). However, if we remove FRAG2, the bundler at the transport will drop a message if it exceeds max_bundle_size.
> Let's therefore bypass message bundling when the transport is TCP (TCP has its own batching).
> TODO: measure how this change affects performance on a 4 node cluster. If positive, commit it.
--
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
12 years, 9 months
[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1663:
--------------------------------
Reducing sock_conn_timeout in TCP will definitely help.
I'm closing this issue as TimeScheduler3 works the way it was designed.
> TimeScheduler3 could spawn too many threads
> -------------------------------------------
>
> Key: JGRP-1663
> URL: https://issues.jboss.org/browse/JGRP-1663
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Igor Mazur
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 3.4
>
> Attachments: global.xml, site.xml
>
>
> With default timer thread pool settings this code could spawn thousands of threads:
> protected void submitToPool(final Task entry) {
> try {
> pool.execute(entry);
> }
> catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort"
> Thread thread=timer_thread_factory != null?
> timer_thread_factory.newThread(entry, "Timer temp thread")
> : new Thread(entry, "Timer temp thread");
> thread.start();
> }
> }
> On my environment I got 19000 threads.
--
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
12 years, 9 months
[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1663.
----------------------------
Resolution: Rejected
> TimeScheduler3 could spawn too many threads
> -------------------------------------------
>
> Key: JGRP-1663
> URL: https://issues.jboss.org/browse/JGRP-1663
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Igor Mazur
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 3.4
>
> Attachments: global.xml, site.xml
>
>
> With default timer thread pool settings this code could spawn thousands of threads:
> protected void submitToPool(final Task entry) {
> try {
> pool.execute(entry);
> }
> catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort"
> Thread thread=timer_thread_factory != null?
> timer_thread_factory.newThread(entry, "Timer temp thread")
> : new Thread(entry, "Timer temp thread");
> thread.start();
> }
> }
> On my environment I got 19000 threads.
--
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
12 years, 9 months
[JBoss JIRA] (JGRP-1661) AUTH bypasses join requests without auth_headers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1661?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1661.
----------------------------
Resolution: Done
When a join or merge request with an AUTH header is encountered, the request will be denied. Also added support for message batches
> AUTH bypasses join requests without auth_headers
> ------------------------------------------------
>
> Key: JGRP-1661
> URL: https://issues.jboss.org/browse/JGRP-1661
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Sergey Tumashov
> Assignee: Bela Ban
> Fix For: 3.3.4, 3.4
>
>
> The cluster coordinator allows new members to join the cluster if their join requests do not contain auth headers.
> A simple test case would involve two nodes. One node should be configured to use a protocol stack with AUTH. The other node should use the same stack but with AUTH excluded. The node that uses AUTH needs to be brought up first so it can become cluster coordinator. The second node will now successfully join the cluster even though it does not send any auth tokens along with its join requests.
--
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
12 years, 9 months
[JBoss JIRA] (WFLY-1726) Unable to add Option with a value containing whitespaces to a Security Domain Module
by Alejandro Rodríguez (JIRA)
Alejandro Rodríguez created WFLY-1726:
-----------------------------------------
Summary: Unable to add Option with a value containing whitespaces to a Security Domain Module
Key: WFLY-1726
URL: https://issues.jboss.org/browse/WFLY-1726
Project: WildFly
Issue Type: Bug
Components: Web Console
Reporter: Alejandro Rodríguez
Assignee: Heiko Braun
When you try to add a Module Option to a Login Module of a Security Domain, when you save, if the value contains spaces, you get an error next to the Value field saying "Invalid input: no whitespace, no special chars", even though this should be allowed for Login Module Options (for example, to enter a query).
--
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
12 years, 9 months
[JBoss JIRA] (WFLY-1374) Unable to start JBoss server after issuing kill -9
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/WFLY-1374?page=com.atlassian.jira.plugin.... ]
Osamu Nagano commented on WFLY-1374:
------------------------------------
Pasted the stack trace so it is searchable. The workaround is mark the server stopped explicitly by {{/host=<HOSTNAME>/server-config=<SERVERNAME>:stop}}.
{noformat}
15:53:56,803 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: java.util.concurrent.ExecutionEx
ception: Operation failed
at org.jboss.as.server.ServerStartTask$2$1.load(ServerStartTask.java:179) [jboss-as-server-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.server.ServerService.boot(ServerService.java:308) [jboss-as-server-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:188) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
Caused by: java.util.concurrent.ExecutionException: Operation failed
at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74) [jboss-threads-2.1.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268) [jboss-threads-2.1.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$2.get(ServerBootOperationsService.java:107) [jboss-as-server-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.server.mgmt.domain.ServerBootOperationsService$2.get(ServerBootOperationsService.java:89) [jboss-as-server-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.server.ServerStartTask$2$1.load(ServerStartTask.java:176) [jboss-as-server-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
... 3 more
Caused by: java.io.IOException: no context to delegate with id: -1098589448
at org.jboss.as.protocol.mgmt.AbstractManagementRequest.handleFailed(AbstractManagementRequest.java:63) [jboss-as-protocol-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ActiveRequest.handleFailed(AbstractMessageHandler.java:485) [jboss-as-protocol-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:112) [jboss-as-protocol-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1.handleMessage(ManagementChannelReceiver.java:58) [jboss-as-protocol-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:86) [jboss-as-protocol-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:435) [jboss-remoting-3.2.16.GA-redhat-1.jar:3.2.16.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
... 1 more
15:53:56,812 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{noformat}
> Unable to start JBoss server after issuing kill -9
> --------------------------------------------------
>
> Key: WFLY-1374
> URL: https://issues.jboss.org/browse/WFLY-1374
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Reporter: Emanuel Muckenhuber
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.Beta1
>
>
> After manually killing a server it fails on subsequent start attempt using the management console or CLI.
--
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
12 years, 9 months