[jira] [Commented] (DIRMINA-1088) OrderedThreadPool implementation should be compatible with Java 10
[
https://issues.apache.org/jira/browse/DIRMINA-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527732#comment-16527732
]
Guus der Kinderen commented on DIRMINA-1088:
I think the problem is resolved by setting Max before Core. That should have
negligible side-effects otherwise. I've attached a patch to this issue.
> OrderedThreadPool implementation should be compatible with Java 10
> --
>
> Key: DIRMINA-1088
> URL: https://issues.apache.org/jira/browse/DIRMINA-1088
> Project: MINA
> Issue Type: Bug
> Components: Core
>Reporter: Guus der Kinderen
>Priority: Major
> Attachments: orderedthreadpool.patch
>
>
> {{org.apache.mina.filter.executor.OrderedThreadPoolExecutor}} inherits from
> {{java.util.concurrent.ThreadPoolExecutor}}
> OrderedThreadPoolExecutor, in its constructor, calls these two methods from
> its parent to determine pool sizing:
> {code:java}
> super.setCorePoolSize(corePoolSize);
> super.setMaximumPoolSize(maximumPoolSize);{code}
> This works fine up until Java 8. In Java 10 (possibly 9 - I did not check),
> an additional input validation was added to
> {{ThreadPoolExecutor#setCorePoolSize}}: {{maximumPoolSize < corePoolSize}}
> ThreadPoolExecutor Java 8:
> {code:java}
> public void setCorePoolSize(int corePoolSize) {
> if (corePoolSize < 0)
> throw new IllegalArgumentException();
> public void setMaximumPoolSize(int maximumPoolSize) {
> if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> {code}
> ThreadPoolExecutor Java 10:
> {code:java}
> public void setCorePoolSize(int corePoolSize) {
> if (corePoolSize < 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> public void setMaximumPoolSize(int maximumPoolSize) {
> if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> {code}
> As a result, the first line of this part of the constructor of
> OrderedThreadPoolExecutor now throws an IllegalArgumentException.
> {code:java}
> super.setCorePoolSize(corePoolSize);
> super.setMaximumPoolSize(maximumPoolSize);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DIRMINA-1088) OrderedThreadPool implementation should be compatible with Java 10
[
https://issues.apache.org/jira/browse/DIRMINA-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guus der Kinderen updated DIRMINA-1088:
---
Attachment: orderedthreadpool.patch
> OrderedThreadPool implementation should be compatible with Java 10
> --
>
> Key: DIRMINA-1088
> URL: https://issues.apache.org/jira/browse/DIRMINA-1088
> Project: MINA
> Issue Type: Bug
> Components: Core
>Reporter: Guus der Kinderen
>Priority: Major
> Attachments: orderedthreadpool.patch
>
>
> {{org.apache.mina.filter.executor.OrderedThreadPoolExecutor}} inherits from
> {{java.util.concurrent.ThreadPoolExecutor}}
> OrderedThreadPoolExecutor, in its constructor, calls these two methods from
> its parent to determine pool sizing:
> {code:java}
> super.setCorePoolSize(corePoolSize);
> super.setMaximumPoolSize(maximumPoolSize);{code}
> This works fine up until Java 8. In Java 10 (possibly 9 - I did not check),
> an additional input validation was added to
> {{ThreadPoolExecutor#setCorePoolSize}}: {{maximumPoolSize < corePoolSize}}
> ThreadPoolExecutor Java 8:
> {code:java}
> public void setCorePoolSize(int corePoolSize) {
> if (corePoolSize < 0)
> throw new IllegalArgumentException();
> public void setMaximumPoolSize(int maximumPoolSize) {
> if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> {code}
> ThreadPoolExecutor Java 10:
> {code:java}
> public void setCorePoolSize(int corePoolSize) {
> if (corePoolSize < 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> public void setMaximumPoolSize(int maximumPoolSize) {
> if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> {code}
> As a result, the first line of this part of the constructor of
> OrderedThreadPoolExecutor now throws an IllegalArgumentException.
> {code:java}
> super.setCorePoolSize(corePoolSize);
> super.setMaximumPoolSize(maximumPoolSize);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DIRMINA-1088) OrderedThreadPool implementation should be compatible with Java 10
[
https://issues.apache.org/jira/browse/DIRMINA-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guus der Kinderen updated DIRMINA-1088:
---
Description:
{{org.apache.mina.filter.executor.OrderedThreadPoolExecutor}} inherits from
{{java.util.concurrent.ThreadPoolExecutor}}
OrderedThreadPoolExecutor, in its constructor, calls these two methods from its
parent to determine pool sizing:
{code:java}
super.setCorePoolSize(corePoolSize);
super.setMaximumPoolSize(maximumPoolSize);{code}
This works fine up until Java 8. In Java 10 (possibly 9 - I did not check), an
additional input validation was added to
{{ThreadPoolExecutor#setCorePoolSize}}: {{maximumPoolSize < corePoolSize}}
ThreadPoolExecutor Java 8:
{code:java}
public void setCorePoolSize(int corePoolSize) {
if (corePoolSize < 0)
throw new IllegalArgumentException();
public void setMaximumPoolSize(int maximumPoolSize) {
if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
{code}
ThreadPoolExecutor Java 10:
{code:java}
public void setCorePoolSize(int corePoolSize) {
if (corePoolSize < 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
public void setMaximumPoolSize(int maximumPoolSize) {
if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
{code}
As a result, the first line of this part of the constructor of
OrderedThreadPoolExecutor now throws an IllegalArgumentException.
{code:java}
super.setCorePoolSize(corePoolSize);
super.setMaximumPoolSize(maximumPoolSize);{code}
was:
{{org.apache.mina.filter.executor.OrderedThreadPoolExecutor}} inherits from
{{java.util.concurrent.ThreadPoolExecutor}}
OrderedThreadPool, in its constructor, calls these two methods from its parent
to determine pool sizing:
{code:java}
super.setCorePoolSize(corePoolSize);
super.setMaximumPoolSize(maximumPoolSize);{code}
This works fine up until Java 8. In Java 10 (possibly 9 - I did not check), an
additional input validation was added to
{{ThreadPoolExecutor#setCorePoolSize}}: {{maximumPoolSize < corePoolSize}}
ThreadPoolExecutor Java 8:
{code:java}
public void setCorePoolSize(int corePoolSize) {
if (corePoolSize < 0)
throw new IllegalArgumentException();
public void setMaximumPoolSize(int maximumPoolSize) {
if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
{code}
ThreadPoolExecutor Java 10:
{code:java}
public void setCorePoolSize(int corePoolSize) {
if (corePoolSize < 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
public void setMaximumPoolSize(int maximumPoolSize) {
if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
{code}
As a result, the first line of this part of the constructor of
OrderedThreadPool now throws an IllegalArgumentException.
{code:java}
super.setCorePoolSize(corePoolSize);
super.setMaximumPoolSize(maximumPoolSize);{code}
> OrderedThreadPool implementation should be compatible with Java 10
> --
>
> Key: DIRMINA-1088
> URL: https://issues.apache.org/jira/browse/DIRMINA-1088
> Project: MINA
> Issue Type: Bug
> Components: Core
>Reporter: Guus der Kinderen
>Priority: Major
>
> {{org.apache.mina.filter.executor.OrderedThreadPoolExecutor}} inherits from
> {{java.util.concurrent.ThreadPoolExecutor}}
> OrderedThreadPoolExecutor, in its constructor, calls these two methods from
> its parent to determine pool sizing:
> {code:java}
> super.setCorePoolSize(corePoolSize);
> super.setMaximumPoolSize(maximumPoolSize);{code}
> This works fine up until Java 8. In Java 10 (possibly 9 - I did not check),
> an additional input validation was added to
> {{ThreadPoolExecutor#setCorePoolSize}}: {{maximumPoolSize < corePoolSize}}
> ThreadPoolExecutor Java 8:
> {code:java}
> public void setCorePoolSize(int corePoolSize) {
> if (corePoolSize < 0)
> throw new IllegalArgumentException();
> public void setMaximumPoolSize(int maximumPoolSize) {
> if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> {code}
> ThreadPoolExecutor Java 10:
> {code:java}
> public void setCorePoolSize(int corePoolSize) {
> if (corePoolSize < 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> public void setMaximumPoolSize(int maximumPoolSize) {
> if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
> throw new IllegalArgumentException();
> {code}
> As a
[jira] [Created] (DIRMINA-1088) OrderedThreadPool implementation should be compatible with Java 10
Guus der Kinderen created DIRMINA-1088:
--
Summary: OrderedThreadPool implementation should be compatible
with Java 10
Key: DIRMINA-1088
URL: https://issues.apache.org/jira/browse/DIRMINA-1088
Project: MINA
Issue Type: Bug
Components: Core
Reporter: Guus der Kinderen
{{org.apache.mina.filter.executor.OrderedThreadPoolExecutor}} inherits from
{{java.util.concurrent.ThreadPoolExecutor}}
OrderedThreadPool, in its constructor, calls these two methods from its parent
to determine pool sizing:
{code:java}
super.setCorePoolSize(corePoolSize);
super.setMaximumPoolSize(maximumPoolSize);{code}
This works fine up until Java 8. In Java 10 (possibly 9 - I did not check), an
additional input validation was added to
{{ThreadPoolExecutor#setCorePoolSize}}: {{maximumPoolSize < corePoolSize}}
ThreadPoolExecutor Java 8:
{code:java}
public void setCorePoolSize(int corePoolSize) {
if (corePoolSize < 0)
throw new IllegalArgumentException();
public void setMaximumPoolSize(int maximumPoolSize) {
if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
{code}
ThreadPoolExecutor Java 10:
{code:java}
public void setCorePoolSize(int corePoolSize) {
if (corePoolSize < 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
public void setMaximumPoolSize(int maximumPoolSize) {
if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize)
throw new IllegalArgumentException();
{code}
As a result, the first line of this part of the constructor of
OrderedThreadPool now throws an IllegalArgumentException.
{code:java}
super.setCorePoolSize(corePoolSize);
super.setMaximumPoolSize(maximumPoolSize);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1078) OrderedThreadPoolExecutor should allow sessions to be prioritized
[
https://issues.apache.org/jira/browse/DIRMINA-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527603#comment-16527603
]
Emmanuel Lecharny commented on DIRMINA-1078:
Hi Jonathan, I'm busy today, so if you want to take care of it it would be very
appreciated...
> OrderedThreadPoolExecutor should allow sessions to be prioritized
> -
>
> Key: DIRMINA-1078
> URL: https://issues.apache.org/jira/browse/DIRMINA-1078
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: Guus der Kinderen
>Priority: Minor
> Attachments: 20180216.patch
>
>
> The functionality provided in {{OrderedThreadPoolExecutor}} should be
> augmented to, optionally, allow for assignment of priority to certain
> sessions over others.
> We've introduced this functionality after observing issues in a deployment
> where system resources where being starved by the sheer amount of sessions
> that attempted to perform TLS. Without the class introduced by this commit,
> events for any session could eventually fail (time-out), causing the session
> to fail. If that session happened to be a session that had already
> established TLS, the resources that were spent on establishing TLS are
> wasted. The negative effect is amplified by the fact that a typical client in
> such a situation would attempt
> to reconnect, which further adds to the load of the system already being
> starved.
> With the modifications introduced by the patch provided in this issue,
> priority can be given to sessions that have already established TLS. This
> dramatically reduces the issue described above, as the first sessions to fail
> will be those that are still negotiating TLS. Using a specialized
> {{Comparator}}, one can even prioritize between these, causing sessions for
> which least effort has performed to fail before sessions that are more likely
> to near TLS completion.
> The patch intends to add this feature as optional functionality to the
> existing implementation, with little side effects to the existing, default
> behavior.
> The implementation provided here was initially based on a copy of the
> implementation of {{OrderedThreadPoolExecutor}} that introduced a
> considerable amount of code duplication. For illustrative purposes, the line
> of commits leading from that initial commit to the patch attached to this
> JIRA issue can be found at
> [https://github.com/guusdk/mina/commit/c0a421cf445696fbfd4d5b10d650d7c71d8faab7]
> and later commits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1078) OrderedThreadPoolExecutor should allow sessions to be prioritized
[
https://issues.apache.org/jira/browse/DIRMINA-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527593#comment-16527593
]
Jonathan Valliere commented on DIRMINA-1078:
[~elecharny] Are you going to take charge of this one or should I?
> OrderedThreadPoolExecutor should allow sessions to be prioritized
> -
>
> Key: DIRMINA-1078
> URL: https://issues.apache.org/jira/browse/DIRMINA-1078
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: Guus der Kinderen
>Priority: Minor
> Attachments: 20180216.patch
>
>
> The functionality provided in {{OrderedThreadPoolExecutor}} should be
> augmented to, optionally, allow for assignment of priority to certain
> sessions over others.
> We've introduced this functionality after observing issues in a deployment
> where system resources where being starved by the sheer amount of sessions
> that attempted to perform TLS. Without the class introduced by this commit,
> events for any session could eventually fail (time-out), causing the session
> to fail. If that session happened to be a session that had already
> established TLS, the resources that were spent on establishing TLS are
> wasted. The negative effect is amplified by the fact that a typical client in
> such a situation would attempt
> to reconnect, which further adds to the load of the system already being
> starved.
> With the modifications introduced by the patch provided in this issue,
> priority can be given to sessions that have already established TLS. This
> dramatically reduces the issue described above, as the first sessions to fail
> will be those that are still negotiating TLS. Using a specialized
> {{Comparator}}, one can even prioritize between these, causing sessions for
> which least effort has performed to fail before sessions that are more likely
> to near TLS completion.
> The patch intends to add this feature as optional functionality to the
> existing implementation, with little side effects to the existing, default
> behavior.
> The implementation provided here was initially based on a copy of the
> implementation of {{OrderedThreadPoolExecutor}} that introduced a
> considerable amount of code duplication. For illustrative purposes, the line
> of commits leading from that initial commit to the patch attached to this
> JIRA issue can be found at
> [https://github.com/guusdk/mina/commit/c0a421cf445696fbfd4d5b10d650d7c71d8faab7]
> and later commits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Le 29/06/2018 à 13:10, Guillaume Nodet a écrit : > Sorry for the delay. > I gave it another try and unfortunately, the problem persists with my local > build of 2.20-SNAPSHOT. Ah, crap :/ > I'll try to find a fix next week. Okiedo. What is surprizing is that I fixed the change you pointed, so it must be something different... -- Emmanuel Lecharny Symas.com directory.apache.org pEpkey.asc Description: application/pgp-keys
Re: Fwd: Upgrade to Mina 2.0.19 broke camel-xmpp tests
Sorry for the delay. I gave it another try and unfortunately, the problem persists with my local build of 2.20-SNAPSHOT. I'll try to find a fix next week. Le mar. 26 juin 2018 à 00:39, Emmanuel Lécharny a écrit : > > > Le 23/06/2018 à 01:40, Guillaume Nodet a écrit : > > Sorry, I've been on meetings the whole week. I'll give it a try on > monday. > > Hi Guillaume, > > any update ? > > Thanks ! > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org > > -- Guillaume Nodet
[jira] [Commented] (DIRMINA-1078) OrderedThreadPoolExecutor should allow sessions to be prioritized
[
https://issues.apache.org/jira/browse/DIRMINA-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527330#comment-16527330
]
Guus der Kinderen commented on DIRMINA-1078:
No worries, thanks for the update.
> OrderedThreadPoolExecutor should allow sessions to be prioritized
> -
>
> Key: DIRMINA-1078
> URL: https://issues.apache.org/jira/browse/DIRMINA-1078
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: Guus der Kinderen
>Priority: Minor
> Attachments: 20180216.patch
>
>
> The functionality provided in {{OrderedThreadPoolExecutor}} should be
> augmented to, optionally, allow for assignment of priority to certain
> sessions over others.
> We've introduced this functionality after observing issues in a deployment
> where system resources where being starved by the sheer amount of sessions
> that attempted to perform TLS. Without the class introduced by this commit,
> events for any session could eventually fail (time-out), causing the session
> to fail. If that session happened to be a session that had already
> established TLS, the resources that were spent on establishing TLS are
> wasted. The negative effect is amplified by the fact that a typical client in
> such a situation would attempt
> to reconnect, which further adds to the load of the system already being
> starved.
> With the modifications introduced by the patch provided in this issue,
> priority can be given to sessions that have already established TLS. This
> dramatically reduces the issue described above, as the first sessions to fail
> will be those that are still negotiating TLS. Using a specialized
> {{Comparator}}, one can even prioritize between these, causing sessions for
> which least effort has performed to fail before sessions that are more likely
> to near TLS completion.
> The patch intends to add this feature as optional functionality to the
> existing implementation, with little side effects to the existing, default
> behavior.
> The implementation provided here was initially based on a copy of the
> implementation of {{OrderedThreadPoolExecutor}} that introduced a
> considerable amount of code duplication. For illustrative purposes, the line
> of commits leading from that initial commit to the patch attached to this
> JIRA issue can be found at
> [https://github.com/guusdk/mina/commit/c0a421cf445696fbfd4d5b10d650d7c71d8faab7]
> and later commits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1078) OrderedThreadPoolExecutor should allow sessions to be prioritized
[
https://issues.apache.org/jira/browse/DIRMINA-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527253#comment-16527253
]
Emmanuel Lecharny commented on DIRMINA-1078:
Still have to review and merge the code... Being swamped into day job and
family stuff atm :/
> OrderedThreadPoolExecutor should allow sessions to be prioritized
> -
>
> Key: DIRMINA-1078
> URL: https://issues.apache.org/jira/browse/DIRMINA-1078
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: Guus der Kinderen
>Priority: Minor
> Attachments: 20180216.patch
>
>
> The functionality provided in {{OrderedThreadPoolExecutor}} should be
> augmented to, optionally, allow for assignment of priority to certain
> sessions over others.
> We've introduced this functionality after observing issues in a deployment
> where system resources where being starved by the sheer amount of sessions
> that attempted to perform TLS. Without the class introduced by this commit,
> events for any session could eventually fail (time-out), causing the session
> to fail. If that session happened to be a session that had already
> established TLS, the resources that were spent on establishing TLS are
> wasted. The negative effect is amplified by the fact that a typical client in
> such a situation would attempt
> to reconnect, which further adds to the load of the system already being
> starved.
> With the modifications introduced by the patch provided in this issue,
> priority can be given to sessions that have already established TLS. This
> dramatically reduces the issue described above, as the first sessions to fail
> will be those that are still negotiating TLS. Using a specialized
> {{Comparator}}, one can even prioritize between these, causing sessions for
> which least effort has performed to fail before sessions that are more likely
> to near TLS completion.
> The patch intends to add this feature as optional functionality to the
> existing implementation, with little side effects to the existing, default
> behavior.
> The implementation provided here was initially based on a copy of the
> implementation of {{OrderedThreadPoolExecutor}} that introduced a
> considerable amount of code duplication. For illustrative purposes, the line
> of commits leading from that initial commit to the patch attached to this
> JIRA issue can be found at
> [https://github.com/guusdk/mina/commit/c0a421cf445696fbfd4d5b10d650d7c71d8faab7]
> and later commits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
