Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread Bindul Bhowmik 
On Tue, Feb 6, 2018 at 7:17 AM, Oleg Kalnichevski  wrote:
> On Mon, 2018-02-05 at 23:39 -0700, Bindul Bhowmik wrote:
>
> ...
>
>>
>> If I may ask as a user of the library, would the new site still have
>> parts of the site that are generated from releases? For example,
>> Javadocs?
>>
>
> Hi Bindul
>
> Yes, most certainly javadocs would still be there (given that javadoc
> content gets published to ASF Nexus / Maven Central with every release
> and therefore is available) but some Maven generated reports would
> likely be lost. I _personally_ never found them useful, so I do not see
> it as a big loss.

Hi Oleg,

Thank you for taking that into consideration.

>
>
>> Also, irrespective of the site generation tool or content format
>> selection, would it help to move the generated site to git (use
>> gitpubsub) and have the site built/published from Jenkins? I happened
>> to see a discussion [1] on builds@a.o recently about it. Looks like
>> the tooling will also be able to provide a staging site (soon).
>>
>
> Absolutely. Being able to take a full advantage of better tooling is a
> primary motivating factor for me to consider migration to Jekyll or a
> similar content rendering engine.
>
> This is a great example of a good project web site
>
> http://struts.apache.org/getting-started/

Good stuff. However, looks like the struts folks also maintain a full
maven site (http://struts.apache.org/maven/) under the main site. And
looks like they are using Jekyll and Jenkins as well
(https://lists.apache.org/thread.html/%3CCAMopvkO7VJ+pKtipKMEvEZ2udVMk5-JWymmjvF=jjfbdalo...@mail.gmail.com%3E).

>
> What makes it massively better is not a prettier look but that 'Edit on
> GitHub' button.

I was going to mention that I remember seeing something similar on the
maven lists, as Michael mentioned.

Bindul

>
> Oleg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Comment Edited] (HTTPCORE-509) AVAIL_PROCS is autoconfigured based on core count

2018-02-06 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354471#comment-16354471
 ] 

Gary Gregory edited comment on HTTPCORE-509 at 2/6/18 7:59 PM:
---

[~olegk]: What do you think about addressing this ticket as follows (diff for 
{{4.4.x}}):

{noformat}
diff --git 
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
 
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
index 26fb11ea5..ecda462e5 100644
--- 
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
+++ 
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
@@ -27,6 +27,9 @@

 package org.apache.http.impl.nio.reactor;

+import java.security.AccessController;
+import java.security.PrivilegedAction;
+
 import org.apache.http.util.Args;

 /**
@@ -36,6 +39,19 @@
  */
 public final class IOReactorConfig implements Cloneable {

+static int getIntProperty(final String key, final int defaultValue) {
+return AccessController.doPrivileged(new PrivilegedAction() {
+@Override
+public Integer run() {
+final String strValue= System.getProperty(key);
+if (strValue == null) {
+return Integer.valueOf(defaultValue);
+}
+return Integer.valueOf(strValue);
+}
+});
+}
+
 public static final IOReactorConfig DEFAULT = new Builder().build();

 // TODO: make final
@@ -59,7 +75,9 @@ public IOReactorConfig() {
 this.selectInterval = 1000;
 this.shutdownGracePeriod = 500;
 this.interestOpQueued = false;
-this.ioThreadCount = Runtime.getRuntime().availableProcessors();
+this.ioThreadCount = Args.positive(
+getIntProperty("http.IOReactorConfig.ioThreadCount", 
Runtime.getRuntime().availableProcessors()),
+"ioThreadCount");
 this.soTimeout = 0;
 this.soReuseAddress = false;
 this.soLinger = -1;
@@ -394,7 +412,9 @@ public static Builder copy(final IOReactorConfig config) {
 this.selectInterval = 1000;
 this.shutdownGracePeriod = 500;
 this.interestOpQueued = false;
-this.ioThreadCount = Runtime.getRuntime().availableProcessors();
+this.ioThreadCount = Args.positive(
+getIntProperty("http.IOReactorConfig.ioThreadCount", 
Runtime.getRuntime().availableProcessors()),
+"ioThreadCount");
 this.soTimeout = 0;
 this.soReuseAddress = false;
 this.soLinger = -1;
{noformat}

?


was (Author: garydgregory):
[~olegk]: What do you think about addressing this ticket as follows:

{noformat}
diff --git 
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
 
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
index 26fb11ea5..ecda462e5 100644
--- 
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
+++ 
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
@@ -27,6 +27,9 @@

 package org.apache.http.impl.nio.reactor;

+import java.security.AccessController;
+import java.security.PrivilegedAction;
+
 import org.apache.http.util.Args;

 /**
@@ -36,6 +39,19 @@
  */
 public final class IOReactorConfig implements Cloneable {

+static int getIntProperty(final String key, final int defaultValue) {
+return AccessController.doPrivileged(new PrivilegedAction() {
+@Override
+public Integer run() {
+final String strValue= System.getProperty(key);
+if (strValue == null) {
+return Integer.valueOf(defaultValue);
+}
+return Integer.valueOf(strValue);
+}
+});
+}
+
 public static final IOReactorConfig DEFAULT = new Builder().build();

 // TODO: make final
@@ -59,7 +75,9 @@ public IOReactorConfig() {
 this.selectInterval = 1000;
 this.shutdownGracePeriod = 500;
 this.interestOpQueued = false;
-this.ioThreadCount = Runtime.getRuntime().availableProcessors();
+this.ioThreadCount = Args.positive(
+getIntProperty("http.IOReactorConfig.ioThreadCount", 
Runtime.getRuntime().availableProcessors()),
+"ioThreadCount");
 this.soTimeout = 0;
 this.soReuseAddress = false;
 this.soLinger = -1;
@@ -394,7 +412,9 @@ public static Builder copy(final IOReactorConfig config) {
 this.selectInterval = 1000;
 this.shutdownGracePeriod = 500;
 this.interestOpQueued = false;
-this.ioThreadCount = Runtime.getRuntime().availableProcessors();
+this.ioThreadCount = Args.positive(
+

[jira] [Commented] (HTTPCORE-509) AVAIL_PROCS is autoconfigured based on core count

2018-02-06 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354471#comment-16354471
 ] 

Gary Gregory commented on HTTPCORE-509:
---

[~olegk]: What do you think about addressing this ticket as follows:

{noformat}
diff --git 
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
 
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
index 26fb11ea5..ecda462e5 100644
--- 
a/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
+++ 
b/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java
@@ -27,6 +27,9 @@

 package org.apache.http.impl.nio.reactor;

+import java.security.AccessController;
+import java.security.PrivilegedAction;
+
 import org.apache.http.util.Args;

 /**
@@ -36,6 +39,19 @@
  */
 public final class IOReactorConfig implements Cloneable {

+static int getIntProperty(final String key, final int defaultValue) {
+return AccessController.doPrivileged(new PrivilegedAction() {
+@Override
+public Integer run() {
+final String strValue= System.getProperty(key);
+if (strValue == null) {
+return Integer.valueOf(defaultValue);
+}
+return Integer.valueOf(strValue);
+}
+});
+}
+
 public static final IOReactorConfig DEFAULT = new Builder().build();

 // TODO: make final
@@ -59,7 +75,9 @@ public IOReactorConfig() {
 this.selectInterval = 1000;
 this.shutdownGracePeriod = 500;
 this.interestOpQueued = false;
-this.ioThreadCount = Runtime.getRuntime().availableProcessors();
+this.ioThreadCount = Args.positive(
+getIntProperty("http.IOReactorConfig.ioThreadCount", 
Runtime.getRuntime().availableProcessors()),
+"ioThreadCount");
 this.soTimeout = 0;
 this.soReuseAddress = false;
 this.soLinger = -1;
@@ -394,7 +412,9 @@ public static Builder copy(final IOReactorConfig config) {
 this.selectInterval = 1000;
 this.shutdownGracePeriod = 500;
 this.interestOpQueued = false;
-this.ioThreadCount = Runtime.getRuntime().availableProcessors();
+this.ioThreadCount = Args.positive(
+getIntProperty("http.IOReactorConfig.ioThreadCount", 
Runtime.getRuntime().availableProcessors()),
+"ioThreadCount");
 this.soTimeout = 0;
 this.soReuseAddress = false;
 this.soLinger = -1;
{noformat}

?

> AVAIL_PROCS is autoconfigured based on core count
> -
>
> Key: HTTPCORE-509
> URL: https://issues.apache.org/jira/browse/HTTPCORE-509
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Affects Versions: 4.4.9
>Reporter: Elijah Zupancic
>Priority: Major
>
> In [IOReactorConfig:39|
> https://github.com/apache/httpcomponents-core/blob/92c4c6ff64a9a4a0b0677338c03ebd24bfe1b219/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java#L39
> ], the default value for thread count is based on the detected cores on the 
> system. This is usually acceptable. However, if the library is being run 
> within a container where the reported number of CPUs does not match the 
> actual amount of CPU available, you will see too many threads created in the 
> pool leading to performance degradation.
> Of course a direct user of this library will be able to set this value to a 
> sensible number. However, you will typically see httpcore-nio 4-5 steps down 
> the dependency graph and it is being used by other open source components 
> which in turn are being used by other components.
> I would suggest that we optionally read a system parameter for the value of 
> AVAIL_PROCS. If that system parameter is not available, then we use the value 
> of Runtime.getRuntime().availableProcessors();



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-511) Do not cache result of Runtime.getRuntime().availableProcessors() in IOReactorConfig

2018-02-06 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354458#comment-16354458
 ] 

Gary Gregory commented on HTTPCORE-511:
---

Thanks for the heads up [~s...@apache.org].

Not that this change is only effective when a new {{IOReactorConfig}} object is 
created. I do _not_ propose in this ticket to dynamically resize our pools 
based on some metric relative to the number of CPUs available.

> Do not cache result of Runtime.getRuntime().availableProcessors() in 
> IOReactorConfig
> 
>
> Key: HTTPCORE-511
> URL: https://issues.apache.org/jira/browse/HTTPCORE-511
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
>
> Do not cache the result of {{Runtime.getRuntime().availableProcessors()}} in 
> {{IOReactorConfig}} since the result value can change. For example, some 
> virtualization software let you change the number of virtual CPUs while the 
> VM is running.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-511) Do not cache result of Runtime.getRuntime().availableProcessors() in IOReactorConfig

2018-02-06 Thread Sebb (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354441#comment-16354441
 ] 

Sebb commented on HTTPCORE-511:
---

FTR: many physical multi-cpu systems also allow CPUs to be added to or removed 
from the available pool.

> Do not cache result of Runtime.getRuntime().availableProcessors() in 
> IOReactorConfig
> 
>
> Key: HTTPCORE-511
> URL: https://issues.apache.org/jira/browse/HTTPCORE-511
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
>
> Do not cache the result of {{Runtime.getRuntime().availableProcessors()}} in 
> {{IOReactorConfig}} since the result value can change. For example, some 
> virtualization software let you change the number of virtual CPUs while the 
> VM is running.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-511) Do not cache result of Runtime.getRuntime().availableProcessors() in IOReactorConfig

2018-02-06 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed HTTPCORE-511.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3
   4.4.10

> Do not cache result of Runtime.getRuntime().availableProcessors() in 
> IOReactorConfig
> 
>
> Key: HTTPCORE-511
> URL: https://issues.apache.org/jira/browse/HTTPCORE-511
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
>
> Do not cache the result of {{Runtime.getRuntime().availableProcessors()}} in 
> {{IOReactorConfig}} since the result value can change. For example, some 
> virtualization software let you change the number of virtual CPUs while the 
> VM is running.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-511) Do not cache result of Runtime.getRuntime().availableProcessors() in IOReactorConfig

2018-02-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354436#comment-16354436
 ] 

ASF subversion and git services commented on HTTPCORE-511:
--

Commit 8d938a656f0db340b255112f0e97ae71e06e7886 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=8d938a6 ]

[HTTPCORE-511] Do not cache result of
Runtime.getRuntime().availableProcessors() in IOReactorConfig.

> Do not cache result of Runtime.getRuntime().availableProcessors() in 
> IOReactorConfig
> 
>
> Key: HTTPCORE-511
> URL: https://issues.apache.org/jira/browse/HTTPCORE-511
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
>
> Do not cache the result of {{Runtime.getRuntime().availableProcessors()}} in 
> {{IOReactorConfig}} since the result value can change. For example, some 
> virtualization software let you change the number of virtual CPUs while the 
> VM is running.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-511) Do not cache result of Runtime.getRuntime().availableProcessors() in IOReactorConfig

2018-02-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354435#comment-16354435
 ] 

ASF subversion and git services commented on HTTPCORE-511:
--

Commit b1b71bf0cc819e6690cf0a26e8d78027bd1f24a3 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=b1b71bf ]

[HTTPCORE-511] Do not cache result of
Runtime.getRuntime().availableProcessors() in IOReactorConfig.

> Do not cache result of Runtime.getRuntime().availableProcessors() in 
> IOReactorConfig
> 
>
> Key: HTTPCORE-511
> URL: https://issues.apache.org/jira/browse/HTTPCORE-511
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Do not cache the result of {{Runtime.getRuntime().availableProcessors()}} in 
> {{IOReactorConfig}} since the result value can change. For example, some 
> virtualization software let you change the number of virtual CPUs while the 
> VM is running.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-511) Do not cache result of Runtime.getRuntime().availableProcessors() in IOReactorConfig

2018-02-06 Thread Gary Gregory (JIRA) 
Gary Gregory created HTTPCORE-511:
-

 Summary: Do not cache result of 
Runtime.getRuntime().availableProcessors() in IOReactorConfig
 Key: HTTPCORE-511
 URL: https://issues.apache.org/jira/browse/HTTPCORE-511
 Project: HttpComponents HttpCore
  Issue Type: Improvement
  Components: HttpCore NIO
Reporter: Gary Gregory
Assignee: Gary Gregory


Do not cache the result of {{Runtime.getRuntime().availableProcessors()}} in 
{{IOReactorConfig}} since the result value can change. For example, some 
virtualization software let you change the number of virtual CPUs while the VM 
is running.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-510) Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing earlier by checking ioThreadCount in IOReactorConfig constructor.

2018-02-06 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed HTTPCORE-510.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3
   4.4.10

> Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing 
> earlier by checking ioThreadCount in IOReactorConfig constructor.
> -
>
> Key: HTTPCORE-510
> URL: https://issues.apache.org/jira/browse/HTTPCORE-510
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
>
> Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by 
> failing eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} 
> constructor.
> If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
> will get the exception below. This can be avoided by failing earlier in the 
> {{IOReactorConfig}} constructor.
> {noformat}
> java.lang.ArithmeticException: / by zero
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
> {noformat}
> Instead of the above, you will get an {{IllegalArgumentException}} from the 
> {{IOReactorConfig}} constructor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-510) Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing earlier by checking ioThreadCount in IOReactorConfig constructor.

2018-02-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354416#comment-16354416
 ] 

ASF subversion and git services commented on HTTPCORE-510:
--

Commit 2e6e87a7a07ff54ea3fdd76d232295a4f8b7bc05 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=2e6e87a ]

[HTTPCORE-510] Avoid an ArithmeticException in
AbstractMultiworkerIOReactor by failing earlier by checking
ioThreadCount in IOReactorConfig constructor.

> Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing 
> earlier by checking ioThreadCount in IOReactorConfig constructor.
> -
>
> Key: HTTPCORE-510
> URL: https://issues.apache.org/jira/browse/HTTPCORE-510
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by 
> failing eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} 
> constructor.
> If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
> will get the exception below. This can be avoided by failing earlier in the 
> {{IOReactorConfig}} constructor.
> {noformat}
> java.lang.ArithmeticException: / by zero
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
> {noformat}
> Instead of the above, you will get an {{IllegalArgumentException}} from the 
> {{IOReactorConfig}} constructor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-510) Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing earlier by checking ioThreadCount in IOReactorConfig constructor.

2018-02-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16354412#comment-16354412
 ] 

ASF subversion and git services commented on HTTPCORE-510:
--

Commit 1faf0976f723767066293d633ecc83a56358f321 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=1faf097 ]

[HTTPCORE-510] Avoid an ArithmeticException in
AbstractMultiworkerIOReactor by failing earlier by checking
ioThreadCount in IOReactorConfig constructor.

> Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing 
> earlier by checking ioThreadCount in IOReactorConfig constructor.
> -
>
> Key: HTTPCORE-510
> URL: https://issues.apache.org/jira/browse/HTTPCORE-510
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by 
> failing eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} 
> constructor.
> If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
> will get the exception below. This can be avoided by failing earlier in the 
> {{IOReactorConfig}} constructor.
> {noformat}
> java.lang.ArithmeticException: / by zero
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
> {noformat}
> Instead of the above, you will get an {{IllegalArgumentException}} from the 
> {{IOReactorConfig}} constructor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCORE-510) Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing earlier by checking ioThreadCount in IOReactorConfig constructor.

2018-02-06 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated HTTPCORE-510:
--
Description: 
Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by failing 
eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} constructor.

If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
will get the exception below. This can be avoided by failing earlier in the 
{{IOReactorConfig}} constructor.

{noformat}
java.lang.ArithmeticException: / by zero
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
{noformat}

Instead of the above, you will get an {{IllegalArgumentException}} from the 
{{IOReactorConfig}} constructor.


  was:
Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by failing 
eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} constructor.

If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
will get the exception below. This can be avoided by failing earlier in the 
{{IOReactorConfig}} constructor.

{noformat}
java.lang.ArithmeticException: / by zero
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
{noformat}



> Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing 
> earlier by checking ioThreadCount in IOReactorConfig constructor.
> -
>
> Key: HTTPCORE-510
> URL: https://issues.apache.org/jira/browse/HTTPCORE-510
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by 
> failing eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} 
> constructor.
> If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
> will get the exception below. This can be avoided by failing earlier in the 
> {{IOReactorConfig}} constructor.
> {noformat}
> java.lang.ArithmeticException: / by zero
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
> {noformat}
> Instead of the above, you will get an {{IllegalArgumentException}} from the 
> {{IOReactorConfig}} constructor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread Oleg Kalnichevski 
On Tue, 2018-02-06 at 19:46 +0100, Michael Osipov wrote:
> Am 2018-02-06 um 19:39 schrieb Oleg Kalnichevski:
> > On Tue, 2018-02-06 at 16:45 +, sebb wrote:
> > > On 6 February 2018 at 14:31, Oleg Kalnichevski 
> > 
> > ...
> > 
> > > 
> > > > ...
> > > > 
> > > > > I *am* saying we need to preserve links.
> > > > > Moving from Maven may make this harder, so that needs to be
> > > > > factored
> > > > > in to the decision.
> > > > 
> > > > So, we have made a full circle here: I am aware that we should
> > > > preserve
> > > > links, eat healthy, be polite, and stay away from those girls.
> > > 
> > > That tone is not helpful.
> > > 
> > 
> > I can say exactly likewise. Saying that everything is just fine
> > when
> > someone else has to do all the heavy lifting is not helpful and
> > goes
> > counter to the very principles of this organization.
> 
> Please look what Hervé Boutemy has done to the Maven site. All
> source, 
> apt, xdoc, md, can be forked and edited on GitHub. This might be a 
> solution to go for. Just drop him some lines.
> 

Here we go again. I need to drop him a line and ask what exactly? Fix
maven site plugin bloody mess for us? If you are not willing to invest
a minute of your own time how could you possibly expect me to do so?

Besides, I do not see Github doing inside rendering for apt and xdoc
like it can do for markdown.

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCORE-510) Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing earlier by checking ioThreadCount in IOReactorConfig constructor.

2018-02-06 Thread Gary Gregory (JIRA) 

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated HTTPCORE-510:
--
Summary: Avoid an ArithmeticException in AbstractMultiworkerIOReactor by 
failing earlier by checking ioThreadCount in IOReactorConfig constructor.  
(was: Avoid an {{ArithmeticException}} in AbstractMultiworkerIOReactor by 
failing earlier by checking ioThreadCount in IOReactorConfig constructor.)

> Avoid an ArithmeticException in AbstractMultiworkerIOReactor by failing 
> earlier by checking ioThreadCount in IOReactorConfig constructor.
> -
>
> Key: HTTPCORE-510
> URL: https://issues.apache.org/jira/browse/HTTPCORE-510
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by 
> failing eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} 
> constructor.
> If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
> will get the exception below. This can be avoided by failing earlier in the 
> {{IOReactorConfig}} constructor.
> {noformat}
> java.lang.ArithmeticException: / by zero
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
>   at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
>  ~[httpcore-nio-4.4.9.jar:4.4.9]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-510) Avoid an {{ArithmeticException}} in AbstractMultiworkerIOReactor by failing earlier by checking ioThreadCount in IOReactorConfig constructor.

2018-02-06 Thread Gary Gregory (JIRA) 
Gary Gregory created HTTPCORE-510:
-

 Summary: Avoid an {{ArithmeticException}} in 
AbstractMultiworkerIOReactor by failing earlier by checking ioThreadCount in 
IOReactorConfig constructor.
 Key: HTTPCORE-510
 URL: https://issues.apache.org/jira/browse/HTTPCORE-510
 Project: HttpComponents HttpCore
  Issue Type: Improvement
Reporter: Gary Gregory
Assignee: Gary Gregory


Avoid an {{ArithmeticException}} in {{AbstractMultiworkerIOReactor}} by failing 
eariler by checking {{ioThreadCount}} in {{IOReactorConfig}} constructor.

If you build an {{IOReactorConfig}} with an {{ioThreadCount}} equal to 0, you 
will get the exception below. This can be avoided by failing earlier in the 
{{IOReactorConfig}} constructor.

{noformat}
java.lang.ArithmeticException: / by zero
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.addChannel(AbstractMultiworkerIOReactor.java:473)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvent(DefaultListeningIOReactor.java:189)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.DefaultListeningIOReactor.processEvents(DefaultListeningIOReactor.java:151)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:348)
 ~[httpcore-nio-4.4.9.jar:4.4.9]
{noformat}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread Michael Osipov 

Am 2018-02-06 um 19:39 schrieb Oleg Kalnichevski:

On Tue, 2018-02-06 at 16:45 +, sebb wrote:

On 6 February 2018 at 14:31, Oleg Kalnichevski 


...




...


I *am* saying we need to preserve links.
Moving from Maven may make this harder, so that needs to be
factored
in to the decision.


So, we have made a full circle here: I am aware that we should
preserve
links, eat healthy, be polite, and stay away from those girls.


That tone is not helpful.



I can say exactly likewise. Saying that everything is just fine when
someone else has to do all the heavy lifting is not helpful and goes
counter to the very principles of this organization.


Please look what Hervé Boutemy has done to the Maven site. All source, 
apt, xdoc, md, can be forked and edited on GitHub. This might be a 
solution to go for. Just drop him some lines.


Michael


-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread Oleg Kalnichevski 
On Tue, 2018-02-06 at 16:45 +, sebb wrote:
> On 6 February 2018 at 14:31, Oleg Kalnichevski  

...

> 
> > ...
> > 
> > > I *am* saying we need to preserve links.
> > > Moving from Maven may make this harder, so that needs to be
> > > factored
> > > in to the decision.
> > 
> > So, we have made a full circle here: I am aware that we should
> > preserve
> > links, eat healthy, be polite, and stay away from those girls.
> 
> That tone is not helpful.
> 

I can say exactly likewise. Saying that everything is just fine when
someone else has to do all the heavy lifting is not helpful and goes
counter to the very principles of this organization.

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread Oleg Kalnichevski 
On Tue, 2018-02-06 at 16:28 +, sebb wrote:
> On 6 February 2018 at 14:17, Oleg Kalnichevski 
> wrote:
> > On Mon, 2018-02-05 at 23:39 -0700, Bindul Bhowmik wrote:
> > 
> > 

...

> > Absolutely. Being able to take a full advantage of better tooling
> > is a
> > primary motivating factor for me to consider migration to Jekyll or
> > a
> > similar content rendering engine.
> > 
> > This is a great example of a good project web site
> > 
> > http://struts.apache.org/getting-started/
> > 
> > What makes it massively better is not a prettier look but that
> > 'Edit on
> > GitHub' button.
> 
> Which surely could be done with the current HC site?
> 

No, it cant because (1) we do not use markdown (2) site generation
requires custom scripts and multiple maven projects.

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread sebb 
On 6 February 2018 at 14:31, Oleg Kalnichevski  wrote:
> On Tue, 2018-02-06 at 09:55 +, sebb wrote:
>> On 4 February 2018 at 11:49, Oleg Kalnichevski 
>> wrote:
>> > On Sat, 2018-02-03 at 23:02 +, sebb wrote:
>> > > On 3 February 2018 at 10:32, Oleg Kalnichevski 
>> >
>> > ...
>> >
>> > >
>> > > > Like, better tools tend to use markdown.
>> > >
>> > > But Maven is not a content generation tool;
>> >
>> > Why are we using it as a content generation tool I am wondering?
>>
>> We are not; we are using editors etc.
>>
>> Maven is used to generate the presentation of the content as a
>> website
>> or a PDF or whatever.
>>
>
> You are confusing content generation with content authoring.

To my mind, the two are the same.
To generate something is to create it.
So generating content is the same as creating/authoring content.

The site is then generated from the content.

It looks like your phrase "content generation" is what I would call
"site generation".

Or equally, you are thinking of "site content" whereas I am thinking
of information content, i.e. the content of APT, XML or Markdown
files.

> ...
>
>> > and cannot generate sites consisting of multiple versions of
>> > the same artifact.
>>
>> AIUI the multiple sites issue is more about svnpubsub, though
>>
>
> No, it is not about svnpubsub at all. It is about unsuitability of
> Maven site plugin for our project web site.
>
>>
>> > No, Sebastian, all is peachy and Maven site plugin is just fine as
>> > long
>> > as you do not have to touch it.
>>
>> Well, it is working now, is it not?
>>
>
> Working, but badly, so that no one wants to touch it, including myself.
>
> ...
>
>> I *am* saying we need to preserve links.
>> Moving from Maven may make this harder, so that needs to be factored
>> in to the decision.
>
> So, we have made a full circle here: I am aware that we should preserve
> links, eat healthy, be polite, and stay away from those girls.

That tone is not helpful.

> Oleg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread sebb 
On 6 February 2018 at 14:17, Oleg Kalnichevski  wrote:
> On Mon, 2018-02-05 at 23:39 -0700, Bindul Bhowmik wrote:
>
> ...
>
>>
>> If I may ask as a user of the library, would the new site still have
>> parts of the site that are generated from releases? For example,
>> Javadocs?
>>
>
> Hi Bindul
>
> Yes, most certainly javadocs would still be there (given that javadoc
> content gets published to ASF Nexus / Maven Central with every release
> and therefore is available) but some Maven generated reports would
> likely be lost. I _personally_ never found them useful, so I do not see
> it as a big loss.
>
>
>> Also, irrespective of the site generation tool or content format
>> selection, would it help to move the generated site to git (use
>> gitpubsub) and have the site built/published from Jenkins? I happened
>> to see a discussion [1] on builds@a.o recently about it. Looks like
>> the tooling will also be able to provide a staging site (soon).
>>
>
> Absolutely. Being able to take a full advantage of better tooling is a
> primary motivating factor for me to consider migration to Jekyll or a
> similar content rendering engine.
>
> This is a great example of a good project web site
>
> http://struts.apache.org/getting-started/
>
> What makes it massively better is not a prettier look but that 'Edit on
> GitHub' button.

Which surely could be done with the current HC site?

> Oleg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-509) AVAIL_PROCS is autoconfigured based on core count

2018-02-06 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353997#comment-16353997
 ] 

Gary Gregory commented on HTTPCORE-509:
---

Also, our storing this value in a static does not allow for us adapting to the 
value changing...

> AVAIL_PROCS is autoconfigured based on core count
> -
>
> Key: HTTPCORE-509
> URL: https://issues.apache.org/jira/browse/HTTPCORE-509
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Affects Versions: 4.4.9
>Reporter: Elijah Zupancic
>Priority: Major
>
> In [IOReactorConfig:39|
> https://github.com/apache/httpcomponents-core/blob/92c4c6ff64a9a4a0b0677338c03ebd24bfe1b219/httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/IOReactorConfig.java#L39
> ], the default value for thread count is based on the detected cores on the 
> system. This is usually acceptable. However, if the library is being run 
> within a container where the reported number of CPUs does not match the 
> actual amount of CPU available, you will see too many threads created in the 
> pool leading to performance degradation.
> Of course a direct user of this library will be able to set this value to a 
> sensible number. However, you will typically see httpcore-nio 4-5 steps down 
> the dependency graph and it is being used by other open source components 
> which in turn are being used by other components.
> I would suggest that we optionally read a system parameter for the value of 
> AVAIL_PROCS. If that system parameter is not available, then we use the value 
> of Runtime.getRuntime().availableProcessors();



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread Oleg Kalnichevski 
On Tue, 2018-02-06 at 09:55 +, sebb wrote:
> On 4 February 2018 at 11:49, Oleg Kalnichevski 
> wrote:
> > On Sat, 2018-02-03 at 23:02 +, sebb wrote:
> > > On 3 February 2018 at 10:32, Oleg Kalnichevski 
> > 
> > ...
> > 
> > > 
> > > > Like, better tools tend to use markdown.
> > > 
> > > But Maven is not a content generation tool;
> > 
> > Why are we using it as a content generation tool I am wondering?
> 
> We are not; we are using editors etc.
> 
> Maven is used to generate the presentation of the content as a
> website
> or a PDF or whatever.
> 

You are confusing content generation with content authoring. 

...

> AFAICR I have done both, but not recently.
> 

Would you be able to mention any particular contribution of a non-
trivial feature or functionality that had also entailed adding a code
sample to the project website or adding a new section to the tutorial?

...

> 
> > and cannot generate sites consisting of multiple versions of
> > the same artifact.
> 
> AIUI the multiple sites issue is more about svnpubsub, though
> 

No, it is not about svnpubsub at all. It is about unsuitability of
Maven site plugin for our project web site.  

> 
> > No, Sebastian, all is peachy and Maven site plugin is just fine as
> > long
> > as you do not have to touch it.
> 
> Well, it is working now, is it not?
> 

Working, but badly, so that no one wants to touch it, including myself.

...

> I *am* saying we need to preserve links.
> Moving from Maven may make this harder, so that needs to be factored
> in to the decision.

So, we have made a full circle here: I am aware that we should preserve
links, eat healthy, be polite, and stay away from those girls. 

Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread Oleg Kalnichevski 
On Mon, 2018-02-05 at 23:39 -0700, Bindul Bhowmik wrote:

...

> 
> If I may ask as a user of the library, would the new site still have
> parts of the site that are generated from releases? For example,
> Javadocs?
> 

Hi Bindul

Yes, most certainly javadocs would still be there (given that javadoc
content gets published to ASF Nexus / Maven Central with every release
and therefore is available) but some Maven generated reports would
likely be lost. I _personally_ never found them useful, so I do not see
it as a big loss.


> Also, irrespective of the site generation tool or content format
> selection, would it help to move the generated site to git (use
> gitpubsub) and have the site built/published from Jenkins? I happened
> to see a discussion [1] on builds@a.o recently about it. Looks like
> the tooling will also be able to provide a staging site (soon).
> 

Absolutely. Being able to take a full advantage of better tooling is a
primary motivating factor for me to consider migration to Jekyll or a
similar content rendering engine. 

This is a great example of a good project web site

http://struts.apache.org/getting-started/

What makes it massively better is not a prettier look but that 'Edit on
GitHub' button.

Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-06 Thread sebb 
On 4 February 2018 at 11:49, Oleg Kalnichevski  wrote:
> On Sat, 2018-02-03 at 23:02 +, sebb wrote:
>> On 3 February 2018 at 10:32, Oleg Kalnichevski 
>
> ...
>
>>
>> > Like, better tools tend to use markdown.
>>
>> But Maven is not a content generation tool;
>
> Why are we using it as a content generation tool I am wondering?

We are not; we are using editors etc.

Maven is used to generate the presentation of the content as a website
or a PDF or whatever.

>> Preference for markdown and its tooling
>> Content presentation.
>> Site generation.
>>
>> Only the latter is really down to Maven and you have yet to explain
>> what it is about the site generation that is so terrible.
>>
>
> Had you been taking any interest in actually contributing code or
> project web site content you might have known.

AFAICR I have done both, but not recently.

> Maven generates broken links

agreed, but AFAIR it can be fixed in Maven (commons did)

> inconsistent line delimiters that Svn chokes on

Not noticed that. But is it Maven or one of the tools (e.g. Javadoc)
that creates them?

> and cannot generate sites consisting of multiple versions of
> the same artifact.

AIUI the multiple sites issue is more about svnpubsub, though

> I have spent years trying to get it to work (it is
> not a figure of speech) and ended up writing a bunch of gradle scripts
> that stitch together content from multiple maven project, post-process
> the content to fix the links and line delimiters.

Are you sure migration won't involve lots of ongoing work, and then
you discover that the new build system has other features that have to
be worked round?

> No, Sebastian, all is peachy and Maven site plugin is just fine as long
> as you do not have to touch it.

Well, it is working now, is it not?

==

There are several independent but related issues here:
- the content information format
- the site look and feel
- how it is generated.

I think it is important to be clear about the reasons for any change.
So if some existing features are lost, that can be justified in terms
of the benefits.

The site URLs and links should be considered as part of the 'API' of
the documentation.
We should not break them unnecessarily.

Note: I am not arguing that we have to keep Maven to build the site.

I *am* saying we need to preserve links.
Moving from Maven may make this harder, so that needs to be factored
in to the decision.


> Oleg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org