July 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10731) core-threads of ManagedScheduledExecutorService limits number of maximal threads

by gunter zeilinger (JIRA)

gunter zeilinger created WFLY-10731: --------------------------------------- Summary: core-threads of ManagedScheduledExecutorService limits number of maximal threads Key: WFLY-10731 URL: https://issues.jboss.org/browse/WFLY-10731 Project: WildFly Issue Type: Bug Components: EE Affects Versions: 12.0.0.Final Reporter: gunter zeilinger After changing the default configuration: {noformat} <managed-scheduled-executor-services> - <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/> + <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" long-running-tasks="true" core-threads="2" keepalive-time="3000"/> </managed-scheduled-executor-services> {noformat} only 2 (= value of core-threads) threads are used by the Scheduled Executer Service: {code:bash} $ grep $WILDFLY/standalone/log/server.log | tail 2018-07-24 12:03:22,901 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. 2018-07-24 12:03:22,911 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. 2018-07-24 12:03:22,923 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. 2018-07-24 12:03:22,963 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. 2018-07-24 12:03:22,967 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. 2018-07-24 12:03:22,981 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. 2018-07-24 12:03:22,996 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. 2018-07-24 12:03:23,016 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. 2018-07-24 12:03:23,035 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-2) .. 2018-07-24 12:03:23,039 INFO [org.dcm4che3.net.Association] (EE-ManagedScheduledExecutorService-default-Thread-1) .. {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10415) Upgrade to ironjacamar 1.4.10 Final

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10415?page=com.atlassian.jira.plugin... ] Bartosz Baranowski updated WFLY-10415: -------------------------------------- Issue Type: Component Upgrade (was: Bug) > Upgrade to ironjacamar 1.4.10 Final > ----------------------------------- > > Key: WFLY-10415 > URL: https://issues.jboss.org/browse/WFLY-10415 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2230) Multiple discovery protocols without MULTI_PING

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2230?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2230: -------------------------------- Also, perhaps a reactive API (like FIND_MBRS_ASYNC in Discovery), which invokes a callback on each discovery response, can be added to this... > Multiple discovery protocols without MULTI_PING > ----------------------------------------------- > > Key: JGRP-2230 > URL: https://issues.jboss.org/browse/JGRP-2230 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 5.0 > > > Currently, {{MULTI_PING}} is needed to forward discovery requests to multiple discovery protocols. If we change the API in 5.0, and pass a {{Responses}} object down to the discovery protocols, and each discovery protocol forwards discovery requests down (and responses up), and they all add responses to the same {{Responses}} object, then we would not need {{MULTI_PING}} any longer. > However, this is an API change, so can be done only in 5.0. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-2225. -------------------------- Resolution: Won't Do See prev comments; too error-prone... if we implement down(Message), but forget to implement down(MessageBatch), most protocols will be incorrect. > Allow for sending of message batches in JChannel and protocols > -------------------------------------------------------------- > > Key: JGRP-2225 > URL: https://issues.jboss.org/browse/JGRP-2225 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 5.0 > > > Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}. > The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch. > Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2222) Remove deprecated S3_PING and GOOGLE_PING from the codebase

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2222?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2222: -------------------------------- NATIVE_S3_PING [1] is the successor to S3_PING and GOOGLE_PING2 [2] is the successor to GOOGLE_PING. [1] https://github.com/jgroups-extras/native-s3-ping [2] https://github.com/jgroups-extras/jgroups-google > Remove deprecated S3_PING and GOOGLE_PING from the codebase > ----------------------------------------------------------- > > Key: JGRP-2222 > URL: https://issues.jboss.org/browse/JGRP-2222 > Project: JGroups > Issue Type: Task > Reporter: Radoslav Husar > Assignee: Bela Ban > Fix For: 5.0 > > > As discussed on the clustering meeting it is desired to remove the code from the codebase since version 5 to reduce confusion and distribution size. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR

by Bernhard Kabelka (JIRA)

[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ] Bernhard Kabelka commented on WFLY-10630: ----------------------------------------- I have not changed the default configuration of WildFly (other than adding a security-domain for my application). > HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR > --------------------------------------------------------------------------------------- > > Key: WFLY-10630 > URL: https://issues.jboss.org/browse/WFLY-10630 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 13.0.0.Final > Environment: Windows 10, Java 1.8.0_131 > Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final > Reporter: Bernhard Kabelka > Assignee: Bartosz Baranowski > > For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final: > I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session. > In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction. > In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications: > * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out). > * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3974) Make the AuditLogBootingSyslogTest test more forgiving

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3974: ---------------------------------------- Summary: Make the AuditLogBootingSyslogTest test more forgiving Key: WFCORE-3974 URL: https://issues.jboss.org/browse/WFCORE-3974 Project: WildFly Core Issue Type: Task Components: Test Suite Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 6.0.0.Alpha5 This test assumes the boot operations will fit into a predefined number of operations, this is dependent on the default configuration - this test should be testing audit logging on boot not the actual default config so should be more relaxed regarding the number of operations it expects. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ] Bartosz Baranowski commented on WFLY-10630: ------------------------------------------- [~bkabelka] could you please attach example config? > HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR > --------------------------------------------------------------------------------------- > > Key: WFLY-10630 > URL: https://issues.jboss.org/browse/WFLY-10630 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 13.0.0.Final > Environment: Windows 10, Java 1.8.0_131 > Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final > Reporter: Bernhard Kabelka > Assignee: Bartosz Baranowski > > For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final: > I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session. > In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction. > In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications: > * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out). > * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2778) Provide DMO for Scenario Simulation editor

by Toni Rikkola (JIRA)

Toni Rikkola created DROOLS-2778: ------------------------------------ Summary: Provide DMO for Scenario Simulation editor Key: DROOLS-2778 URL: https://issues.jboss.org/browse/DROOLS-2778 Project: Drools Issue Type: Task Components: Scenario Simulation and Testing Reporter: Toni Rikkola Assignee: Toni Rikkola -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10728) RESTEASY008200: JSON Binding deserialization error for valid JSON

by Guido Schmidt (JIRA)

[ https://issues.jboss.org/browse/WFLY-10728?page=com.atlassian.jira.plugin... ] Guido Schmidt commented on WFLY-10728: -------------------------------------- I checked the issue for Wildfly 12. There it's still fine. The regression issue happens in Wildfly 13. > RESTEASY008200: JSON Binding deserialization error for valid JSON > ----------------------------------------------------------------- > > Key: WFLY-10728 > URL: https://issues.jboss.org/browse/WFLY-10728 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 13.0.0.Final > Environment: JDK-10.0.1 > Reporter: Guido Schmidt > Assignee: Ron Sigal > Attachments: User.java, UserQueryForm.java, UsersApi.java > > > I found the following regression issue running the code inside an ejb jar: > In the context of a search for a user for a user via the Wordpress REST API, I get e.g. following String: > {{[{ > "id": 15, > "username": "wpx1", > "name": "Word Press1", > "first_name": "Word", > "last_name": "Press1", > "email": "wpx1(a)pb.com", > "url": "", > "description": "", > "link": "http:\/\/www.pbpiazza.com\/dayc\/archives\/author\/wpx1", > "locale": "en_US", > "nickname": "wpx1", > "slug": "wpx1", > "roles": ["contributor"], > "registered_date": "2018-07-23T08:59:13+00:00", > "capabilities": { > "edit_posts": true, > "read": true, > "level_1": true, > "level_0": true, > "delete_posts": true, > "manage_bookings": true, > "upload_event_images": true, > "delete_events": true, > "edit_events": true, > "read_private_events": true, > "delete_recurring_events": true, > "edit_recurring_events": true, > "edit_locations": true, > "read_private_locations": true, > "read_others_locations": true, > "contributor": true > }, > "extra_capabilities": { > "contributor": true > }, > "avatar_urls": { > "24": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=24&d=mm&r=g", > "48": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=48&d=mm&r=g", > "96": "http:\/\/1.gravatar.com\/avatar\/a4d79ad5a72a13f7d7739c9a3dd9a17b?s=96&d=mm&r=g" > }, > "meta": [], > "_links": { > "self": [{ > "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users\/15" > } > ], > "collection": [{ > "href": "http:\/\/www.pbpiazza.com\/dayc\/wp-json\/wp\/v2\/users" > } > ] > } > } > ]}} > This is achieved by a call of the UsersApi method listUsersAsString: > > ResteasyWebTarget target = (ResteasyWebTarget)restEasy.target(uri); > target.proxy(UsersApi.class); > The call rendering the result into a List<User> fails with error message in the subject. > The result is perfectly fine running Wildfly 11.Plain test cases with Wildfly 13 libraries is also fine. It seems to be a runtime configuration issue of RESTEasy in WIldfly 13. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 July 2018