Re: Tuckey Rewrite URL and infinite loop exception trace for Tomcat 7.0.57

[Kiran Badi]

I resolved it.My bad, to and from rule were having same url mapping and I
feel thats the reason it filter was recursively called and finally
resulting into stackoverflow error.

On Mon, Apr 25, 2016 at 7:02 PM, Kiran Badi  wrote:

> Hi,
>
> I am having some issues with  Tuckey Rewrite URL/Tomcat 7.0.57 and for
> some reasons I believe I am not getting it correct. It seems to me that I
> am getting into infinite loop somewhere.Not sure why but conditions do
> match.
>
>
>  Hello World! This is a link I am
> trying to clean it.
>
> Below is test servlet.
>
>
>  protected void processRequest(HttpServletRequest request,
> HttpServletResponse response)
> throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> try (PrintWriter out = response.getWriter()) {
> String[] params =
> request.getPathInfo().substring(1).split("/");
> System.out.println(params[0]);
> String testid = request.getParameter("testid");
> RequestDispatcher rd =
> request.getRequestDispatcher("/WEB-INF/views/Hello.jsp");
> rd.include(request, response);
> }
> }
>
>
> 
>  http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd;>
>
> 
> 
>
> 
> 
> The rule means that requests to /test/status/ will be
> redirected to /rewrite-status
> the url will be rewritten.
> 
> /test/status/
> %{context-path}/rewrite-status
> 
> 
>  Sample redirect
>  operator="equal">[0-9]
> ^/GetServlet(.*)$
> /GetServlet/testid/%{parameter:testid}
> 
>
> 
> 
> The outbound-rule specifies that when response.encodeURL is
> called (if you are using JSTL c:url)
> the url /rewrite-status will be rewritten to /test/status/.
>
> The above rule and this outbound-rule means that end users
> should never see the
> url /rewrite-status only /test/status/ both in thier location
> bar and in hyperlinks
> in your pages.
> 
> /rewrite-status
> /test/status/
> 
> 
>
>
>
>
>
>
> INFO: org.tuckey.web.filters.urlrewrite.substitution.VariableReplacer
> DEBUG: variable %{parameter:testid} type: parameter, name: 'testid'
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.substitution.VariableReplacer
> DEBUG: resolved to: 50
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.substitution.VariableReplacer
> DEBUG: replaced sb is /GetServlet/testid/50
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.RuleExecutionOutput DEBUG: needs
> to be forwarded to /GetServlet/testid/50
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.utils.ServerNameMatcher DEBUG:
> looking for hostname match on current server name localhost
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.UrlRewriteFilter DEBUG: checking
> for status path on /cleanurl/GetServlet/testid/50
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.UrlRewriter DEBUG: processing
> request for /GetServlet/testid/50
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.UrlRewriter DEBUG: query string
> added
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: Rule 0 run called
> with /GetServlet/testid/50?testid=50
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: Sample redirect
> (rule 1) run called with /GetServlet/testid/50?testid=50
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: matched "from"
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.Condition DEBUG: evaluating "50"
> against [0-9]
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
> INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: conditions match
> Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationDispatcher
> invoke
> SEVERE: Servlet.service() for servlet default threw exception
> java.lang.StackOverflowError
> at
> org.apache.catalina.connector.Request.notifyAttributeAssigned(Request.java:1547)
> at org.apache.catalina.connector.Request.setAttribute(Request.java:1538)
> at
> org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:541)
> at
> 

Tuckey Rewrite URL and infinite loop exception trace for Tomcat 7.0.57

[Kiran Badi]

Hi,

I am having some issues with  Tuckey Rewrite URL/Tomcat 7.0.57 and for some
reasons I believe I am not getting it correct. It seems to me that I am
getting into infinite loop somewhere.Not sure why but conditions do match.


 Hello World! This is a link I am trying
to clean it.

Below is test servlet.


 protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
try (PrintWriter out = response.getWriter()) {
String[] params = request.getPathInfo().substring(1).split("/");
System.out.println(params[0]);
String testid = request.getParameter("testid");
RequestDispatcher rd =
request.getRequestDispatcher("/WEB-INF/views/Hello.jsp");
rd.include(request, response);
}
}



http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd;>






The rule means that requests to /test/status/ will be
redirected to /rewrite-status
the url will be rewritten.

/test/status/
%{context-path}/rewrite-status


 Sample redirect
[0-9]
^/GetServlet(.*)$
/GetServlet/testid/%{parameter:testid}




The outbound-rule specifies that when response.encodeURL is
called (if you are using JSTL c:url)
the url /rewrite-status will be rewritten to /test/status/.

The above rule and this outbound-rule means that end users
should never see the
url /rewrite-status only /test/status/ both in thier location
bar and in hyperlinks
in your pages.

/rewrite-status
/test/status/








INFO: org.tuckey.web.filters.urlrewrite.substitution.VariableReplacer
DEBUG: variable %{parameter:testid} type: parameter, name: 'testid'
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.substitution.VariableReplacer
DEBUG: resolved to: 50
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.substitution.VariableReplacer
DEBUG: replaced sb is /GetServlet/testid/50
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.RuleExecutionOutput DEBUG: needs to
be forwarded to /GetServlet/testid/50
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.utils.ServerNameMatcher DEBUG:
looking for hostname match on current server name localhost
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.UrlRewriteFilter DEBUG: checking
for status path on /cleanurl/GetServlet/testid/50
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.UrlRewriter DEBUG: processing
request for /GetServlet/testid/50
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.UrlRewriter DEBUG: query string
added
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: Rule 0 run called
with /GetServlet/testid/50?testid=50
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: Sample redirect
(rule 1) run called with /GetServlet/testid/50?testid=50
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: matched "from"
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.Condition DEBUG: evaluating "50"
against [0-9]
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationContext log
INFO: org.tuckey.web.filters.urlrewrite.RuleBase DEBUG: conditions match
Apr 25, 2016 6:38:41 PM org.apache.catalina.core.ApplicationDispatcher
invoke
SEVERE: Servlet.service() for servlet default threw exception
java.lang.StackOverflowError
at
org.apache.catalina.connector.Request.notifyAttributeAssigned(Request.java:1547)
at org.apache.catalina.connector.Request.setAttribute(Request.java:1538)
at
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:541)
at
org.apache.catalina.core.ApplicationHttpRequest.setAttribute(ApplicationHttpRequest.java:288)
at
org.apache.catalina.core.ApplicationHttpRequest.setAttribute(ApplicationHttpRequest.java:288)
at
org.apache.catalina.core.ApplicationHttpRequest.setAttribute(ApplicationHttpRequest.java:288)
at
org.apache.catalina.core.ApplicationHttpRequest.setAttribute(ApplicationHttpRequest.java:288)
at
org.apache.catalina.core.ApplicationHttpRequest.setAttribute(ApplicationHttpRequest.java:288)
at

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: OT if/else or not if/else

> If you use else-less-if, then there is never an opportunity for
> parellelization, since the program is going to assume that those
> predicates are (a) independent and (b) ordered in a way that the
> programmer intended.

Not quite true.  Modern compilers and CPU cores will speculatively execute code 
sequences in parallel that may later be abandoned when the results of predicate 
evaluation are available; this can be done for both the if-else-if and the 
else-less-if forms.  Regardless, the if-else-if form is much preferred, in 
terms of providing both the compiler and the maintainer with more information 
(and is certainly not premature optimization, by any stretch of the 
imagination).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/25/16 10:38 AM, Leon Rosenberg wrote:
> On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Leon,
> 
> On 4/22/16 12:24 PM, Leon Rosenberg wrote:
 Hi guys,
 
> 
> I would always choose the case with the elses.
> 
> First, I think it's more clear: if you expect that only one branch
> of the code will run, and no others, then the elses tell the reader
> that fact without any further commentary. The zero-else case might
> help you catch some logic errors (because for example you can log
> each entry into a branch) but there are of course other ways to do
> that.
> 
> Second, it's more efficient, regardless of what type of processor
> you have. Let's take an example where there are more than 3
> branches. How about something like a million branches (just to
> accentuate the point)? If one of the branches runs, the others are
> skipped. If all branches have an equal change of being chosen, then
> the CPU has to perform on average 50 predicates. If you put the
> common cases at the top, you can do even better. Let's assume the
> 80/20 rule applies, here, and you can take a guess that, on
> average, the CPU will only have to perform 10 predicates on
> average.
> 
> 
>> I don't think the example is valid (even if machines with 100.000
>> cpus and more actually exist). But I remember from days of my
>> study, which lies way way back, that languages that are optimized
>> for parallel processing would be able to tell the compiler to
>> execute all ifs in parallel. So if we stick with a number of ifs
>> which is less than the number of available cores/pipes we could
>> run it all in parallel. I don't think it is possible with if
>> else, unless it is transformed into something else.

While there may be some systems that do this kind of thing, Java isn't
one of them. Java is single-threaded unless you explicitly dispatch
work to other threads.

If you use else-less-if, then there is never an opportunity for
parellelization, since the program is going to assume that those
predicates are (a) independent and (b) ordered in a way that the
programmer intended.

If you use if-with-else then those statements are also in intentional
order and -- at someone else said elsewhere in this thread -- the
predicates may have side-effects that could be dangerous to execute
out-of-order (or just "early").

>> The other thing that made me wonder is that most people on the
>> list (or all except me) actually considered if-else-if-else more
>> readable. It not only creates a more complex structure (visually
>> and syntactically  (more letters)). But also the semantics of an
>> *else* are different as of an *if*. This is like North Carolina
>> ;-) if (man){ do_man_thing; } else { do_woman_thing(); } doesn't
>> work anymore, even it worked 20 years ago. Talking about
>> maintaining :-)

You *did* mention that the cases were all mutually exclusive. This is
precisely what if/elseif was designed for.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlced1YACgkQ9CaO5/Lv0PAFXQCfYPdxnWhuAIozpjp6m0/X79B2
fTkAniMHNCkr9nRzXm/A1jNCQVDXB6Ke
=scIU
-END PGP SIGNATURE-

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

Tomcat 8.5 Nio2: java.lang.IllegalStateException: Failed to create Processor for negotiated protocol [""]

[Kreuser, Peter]

Hi there,

I have setup Tomcat 8.5 with the all new SSL Config and HTTP/2.

To test the setup I use testssl.sh (https://testssl.sh ) . The scan is 
successful, also stating HTTP/2 is working. So far so good.

However I see the following exception in the Logs:

25-Apr-2016 17:36:16.697 SEVERE [https-nio2-8443-exec-6] 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading 
request, ignored
java.lang.IllegalStateException: Failed to create Processor for negotiated 
protocol [""]
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:736)
at 
org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.run(Nio2Endpoint.java:1699)
at 
org.apache.tomcat.util.net.Nio2Endpoint.processSocket0(Nio2Endpoint.java:397)
at 
org.apache.tomcat.util.net.Nio2Endpoint.processSocket(Nio2Endpoint.java:382)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:115)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:108)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)
at 
sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
at 
sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
at 
sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
at 
java.nio.channels.AsynchronousSocketChannel.write(AsynchronousSocketChannel.java:577)
at 
org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:273)
at 
org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:204)
at 
org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.run(Nio2Endpoint.java:1676)
at 
org.apache.tomcat.util.net.Nio2Endpoint.processSocket0(Nio2Endpoint.java:397)
at 
org.apache.tomcat.util.net.Nio2Endpoint.processSocket(Nio2Endpoint.java:382)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:98)
at 
org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:91)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
at sun.nio.ch.Invoker$2.run(Invoker.java:218)
at 
sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

The sourcecode of AbstractProtocol.java states:

if (processor == null) {
String negotiatedProtocol = wrapper.getNegotiatedProtocol();
if (negotiatedProtocol != null) {
UpgradeProtocol upgradeProtocol =

getProtocol().getNegotiatedProtocol(negotiatedProtocol);
if (upgradeProtocol != null) {
processor = upgradeProtocol.getProcessor(
wrapper, getProtocol().getAdapter());
} else if (negotiatedProtocol.equals("http/1.1")) {
// Explicitly negotiated the default protocol.
// Obtain a processor below.
} else {
// Failed to create processor. This is a bug.
throw new IllegalStateException(sm.getString(

"abstractConnectionHandler.negotiatedProcessor.fail",
negotiatedProtocol));
}
}
}

So why is this a bug? Should I change something or should Mark T. look into it?

Best regards

Peter

Re: OT if/else or not if/else

[David kerber]

On 4/25/2016 11:44 AM, Leon Rosenberg wrote:

On Mon, Apr 25, 2016 at 5:21 PM, Dougherty, Gregory T., M.S. <
dougherty.greg...@mayo.edu> wrote:




Yes, we do, because, well, it is more informative. :-)

if (a) Š
else if (b) Š
else if (c) Š

Says you have three mutually exclusive options, and implies that a is more
likely / more important than b, than c.

Or, if ³a" is a method call, possibly that ³a² has some setup needed for
³b² and ³c².

All of this is lost with multiple if statements.


Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
optimization is the root of all evil².



Exactly my point.
if (a) Š
if (b) Š
if (c) Š

shorter and therefore easier than the other one ;-) if-else-if is just a
premature optimization to the above statement ;-)


Not necessarily.  Independent IFs have different semantics from an 
if..elseif construct.  In your example, they could all be true, and 
therefore S will be executed 3 times.  In an elseif construct at most 
one will be executed.








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

Re: OT if/else or not if/else

[Dougherty, Gregory T., M.S.]

On 4/25/16, 10:44 AM, "Leon Rosenberg"  wrote:


>On Mon, Apr 25, 2016 at 5:21 PM, Dougherty, Gregory T., M.S. <
>dougherty.greg...@mayo.edu> wrote:
>
>>
>>
>> Yes, we do, because, well, it is more informative. :-)
>>
>> if (a) Š
>> else if (b) Š
>> else if (c) Š
>>
>> Says you have three mutually exclusive options, and implies that a is
>>more
>> likely / more important than b, than c.
>>
>> Or, if ³a" is a method call, possibly that ³a² has some setup needed for
>> ³b² and ³c².
>>
>> All of this is lost with multiple if statements.
>>
>>
>> Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
>> optimization is the root of all evil².
>>
>
>Exactly my point.
>if (a) Š
>if (b) Š
>if (c) Š
>
>shorter and therefore easier than the other one ;-) if-else-if is just a
>premature optimization to the above statement ;-)

No, they’re different statements.

Your code says “any or all of these three options can occur.” But you’ve
told us that is not correct, only one can occur.

So while the code you provide is clean, it is not correct.

Greg


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

Re: OT if/else or not if/else

[Leon Rosenberg]

On Mon, Apr 25, 2016 at 5:21 PM, Dougherty, Gregory T., M.S. <
dougherty.greg...@mayo.edu> wrote:

>
>
> Yes, we do, because, well, it is more informative. :-)
>
> if (a) Š
> else if (b) Š
> else if (c) Š
>
> Says you have three mutually exclusive options, and implies that a is more
> likely / more important than b, than c.
>
> Or, if ³a" is a method call, possibly that ³a² has some setup needed for
> ³b² and ³c².
>
> All of this is lost with multiple if statements.
>
>
> Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
> optimization is the root of all evil².
>

Exactly my point.
if (a) Š
if (b) Š
if (c) Š

shorter and therefore easier than the other one ;-) if-else-if is just a
premature optimization to the above statement ;-)

Re: OT if/else or not if/else

[tomcat]

On 25.04.2016 17:21, Dougherty, Gregory T., M.S. wrote:

On 4/25/16, 9:38 AM, "Leon Rosenberg"  wrote:



The other thing that made me wonder is that most people on the list (or
all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an
*if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)

regards
Leon


Yes, we do, because, well, it is more informative. :-)

if (a) Š
else if (b) Š
else if (c) Š

Says you have three mutually exclusive options, and implies that a is more
likely / more important than b, than c.

Or, if ³a" is a method call, possibly that ³a² has some setup needed for
³b² and ³c².


Now that would be *really* maintainer-unfriendly, to say the least. Talk about obscure 
side-effects. You do not even need a quantum CPU in that case..




All of this is lost with multiple if statements.


Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
optimization is the root of all evil².

Write clean, readable, correct, code.  If nothing else, this will provide
the data for your unit tests when you start optimizing.

Once you have a working implementation, then figure out where your time¹s
being spent.  But your starting pattern should always be ³clean, readable,
correct², and if the options are mutually exclusive ³if .. else if² is
what meets that requirement.

Greg


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




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

Re: OT if/else or not if/else

[Dougherty, Gregory T., M.S.]

On 4/25/16, 9:38 AM, "Leon Rosenberg"  wrote:


>The other thing that made me wonder is that most people on the list (or
>all
>except me) actually considered if-else-if-else more readable. It not only
>creates a more complex structure (visually and syntactically  (more
>letters)). But also the semantics of an *else* are different as of an
>*if*.
>This is like North Carolina ;-)
>if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
>even it worked 20 years ago. Talking about maintaining :-)
>
>regards
>Leon

Yes, we do, because, well, it is more informative. :-)

if (a) Š
else if (b) Š
else if (c) Š

Says you have three mutually exclusive options, and implies that a is more
likely / more important than b, than c.

Or, if ³a" is a method call, possibly that ³a² has some setup needed for
³b² and ³c².

All of this is lost with multiple if statements.


Then there¹s the everlasting wisdom of Knuth¹s comment about "premature
optimization is the root of all evil².

Write clean, readable, correct, code.  If nothing else, this will provide
the data for your unit tests when you start optimizing.

Once you have a working implementation, then figure out where your time¹s
being spent.  But your starting pattern should always be ³clean, readable,
correct², and if the options are mutually exclusive ³if .. else if² is
what meets that requirement.

Greg


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

Re: OT if/else or not if/else

[tomcat]

On 25.04.2016 16:38, Leon Rosenberg wrote:

On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/22/16 12:24 PM, Leon Rosenberg wrote:

Hi guys,



I would always choose the case with the elses.

First, I think it's more clear: if you expect that only one branch of
the code will run, and no others, then the elses tell the reader that
fact without any further commentary. The zero-else case might help you
catch some logic errors (because for example you can log each entry
into a branch) but there are of course other ways to do that.

Second, it's more efficient, regardless of what type of processor you
have. Let's take an example where there are more than 3 branches. How
about something like a million branches (just to accentuate the
point)? If one of the branches runs, the others are skipped. If all
branches have an equal change of being chosen, then the CPU has to
perform on average 50 predicates. If you put the common cases at
the top, you can do even better. Let's assume the 80/20 rule applies,
here, and you can take a guess that, on average, the CPU will only
have to perform 10 predicates on average.



I don't think the example is valid (even if machines with 100.000 cpus and
more actually exist). But I remember from days of my study, which lies way
way back, that languages that are optimized for parallel processing would
be able to tell the compiler to execute all ifs in parallel. So if we stick
with a number of ifs which is less than the number of available cores/pipes
we could run it all in parallel. I don't think it is possible with if else,
unless it is transformed into something else.

The other thing that made me wonder is that most people on the list (or all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an *if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)



And one more thing, as we all write programs that should last for 20 years at least, is 
the advent of quantum computers.  What would be the correct (maintainer-friendly) answer 
once the mere action of testing for a condition may change it ?



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

Re: OT if/else or not if/else

[David kerber]

On 4/25/2016 10:38 AM, Leon Rosenberg wrote:

On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/22/16 12:24 PM, Leon Rosenberg wrote:

Hi guys,



I would always choose the case with the elses.

First, I think it's more clear: if you expect that only one branch of
the code will run, and no others, then the elses tell the reader that
fact without any further commentary. The zero-else case might help you
catch some logic errors (because for example you can log each entry
into a branch) but there are of course other ways to do that.

Second, it's more efficient, regardless of what type of processor you
have. Let's take an example where there are more than 3 branches. How
about something like a million branches (just to accentuate the
point)? If one of the branches runs, the others are skipped. If all
branches have an equal change of being chosen, then the CPU has to
perform on average 50 predicates. If you put the common cases at
the top, you can do even better. Let's assume the 80/20 rule applies,
here, and you can take a guess that, on average, the CPU will only
have to perform 10 predicates on average.



I don't think the example is valid (even if machines with 100.000 cpus and
more actually exist). But I remember from days of my study, which lies way
way back, that languages that are optimized for parallel processing would
be able to tell the compiler to execute all ifs in parallel. So if we stick
with a number of ifs which is less than the number of available cores/pipes
we could run it all in parallel. I don't think it is possible with if else,
unless it is transformed into something else.

The other thing that made me wonder is that most people on the list (or all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an *if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)


I find if...else if...else more readable in that it more clearly 
expresses the programmer's intent that the options are mutually 
exclusive.  If it is done as a series of simple if...end if statements, 
the programmer may know that they're mutually exclusive, but the 
maintainer may not, and will take longer to get up to speed on the code.


If I see independent if...endif statements, I normally assume that 
anywhere from 0 to all of them may be true.




regards
Leon



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

Re: OT if/else or not if/else

[Leon Rosenberg]

On Mon, Apr 25, 2016 at 4:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Leon,
>
> On 4/22/16 12:24 PM, Leon Rosenberg wrote:
> > Hi guys,
> >
>
> I would always choose the case with the elses.
>
> First, I think it's more clear: if you expect that only one branch of
> the code will run, and no others, then the elses tell the reader that
> fact without any further commentary. The zero-else case might help you
> catch some logic errors (because for example you can log each entry
> into a branch) but there are of course other ways to do that.
>
> Second, it's more efficient, regardless of what type of processor you
> have. Let's take an example where there are more than 3 branches. How
> about something like a million branches (just to accentuate the
> point)? If one of the branches runs, the others are skipped. If all
> branches have an equal change of being chosen, then the CPU has to
> perform on average 50 predicates. If you put the common cases at
> the top, you can do even better. Let's assume the 80/20 rule applies,
> here, and you can take a guess that, on average, the CPU will only
> have to perform 10 predicates on average.
>

I don't think the example is valid (even if machines with 100.000 cpus and
more actually exist). But I remember from days of my study, which lies way
way back, that languages that are optimized for parallel processing would
be able to tell the compiler to execute all ifs in parallel. So if we stick
with a number of ifs which is less than the number of available cores/pipes
we could run it all in parallel. I don't think it is possible with if else,
unless it is transformed into something else.

The other thing that made me wonder is that most people on the list (or all
except me) actually considered if-else-if-else more readable. It not only
creates a more complex structure (visually and syntactically  (more
letters)). But also the semantics of an *else* are different as of an *if*.
This is like North Carolina ;-)
if (man){ do_man_thing; } else { do_woman_thing(); } doesn't work anymore,
even it worked 20 years ago. Talking about maintaining :-)

regards
Leon

>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlceJg8ACgkQ9CaO5/Lv0PAODQCfRCBvVgM2HSM2/CBEGtlBe0Pg
> MrcAn2OdBYKJR0OSApcBFfONJHOlKGY0
> =YeMH
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: OT if/else or not if/else

> > Actually, a good compiler should generate the same code for switch
> > and if ... else if, assuming the boolean expressions used with the
> > ifs are compatible with a switch operand.

> Do you know of such a compiler (for Java)? I've never seen a compiler
> generate a switch bytecode when a "switch" statement wasn't present in
> the original Java source.

I'm not talking about the front end, but rather the native code generators 
after optimization (e.g., the C2 compiler for the Oracle JVM).  The bytecodes 
aren't representative of what actually gets executed.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 4/22/16 12:54 PM, Caldarale, Charles R wrote:
>> From: David kerber [mailto:dcker...@verizon.net] Subject: Re: OT
>> if/else or not if/else
> 
>> But I would add that if the conditions can be reduced to
>> enumerations, a Switch would be even faster.
> 
> Actually, a good compiler should generate the same code for switch
> and if ... else if, assuming the boolean expressions used with the
> ifs are compatible with a switch operand.

Do you know of such a compiler (for Java)? I've never seen a compiler
generate a switch bytecode when a "switch" statement wasn't present in
the original Java source. My experience has been that the Java
compiler itself is fairly dumb, and the most optimizations seem to be
performed by the JIT which knows much more about what's really going
to happen than the Java-bytecode compiler.

(Admittedly, I haven't played with this in quite a while, and I never
really did a survey of compilers.)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlceJt0ACgkQ9CaO5/Lv0PCwsQCcCZTs9ktsGh1m6RaetdAt5Iyd
LyYAmQG2HMoz1A6ps5oZPQ65IaLAY/yJ
=FKW2
-END PGP SIGNATURE-

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

Re: Small problems compiling tomcat native

[Stefan Frei]

ok thx for the hint. dunno why debian still provides 1.0.1.

anyway i plan to migrate the production to ubuntu, im almost sure they
have a more recent openssl.

i only took the 1.1 release because of the old ssl.

Regards

Stefan

2016-04-25 14:57 GMT+02:00 Rainer Jung :
> Am 25.04.2016 um 14:31 schrieb Stefan Frei:
>>
>> very sorry just solved it.
>>
>>
>> overlooked a line in configure
>>
>> /root/tomcat-native-1.1.34-src/jni/native/build/get-version.sh:
>> Permission denied
>
>
> OK, no problem. If extracted from a source tarball, the file should have
> been executable by default though. It might be it is not if you picked a zip
> file source download.
>
> Another comment: OpenSSL 1.0.1k is pretty old. 1.0.1s is current for 1.0.1
> and even better would be 1.0.2g but it might be, that you won't find such a
> packet for your OS version. You could compile 1.0.2g yourself though and
> install in a separate directory. Using 1.0.2 you could switch to tcnative
> 1.2.x (which needs OpenSSL 1.0.2). The current tcnative 1.2.x is 1.2.5, but
> a 1.2.6 will likely be released during the next few days.
>
> There are currently no plans for another tcnative 1.1.x release.
>
> Regards,
>
> Rainer
>
>
>> 2016-04-25 14:04 GMT+02:00 Rainer Jung :
>>>
>>> Can you provide the full configure command you use and the configure and
>>> make output as well as config.log? Do you have environment variables set,
>>> that influence the build (CC, CFLAGS, LDFLAGS or similar)?
>>>
>>> The "-Wl,-z,relro" should not directly come from our own tcnative scripts
>>> but using the make output (and configure output) we can double check.
>>>
>>> It could be, that those flags come from and APR or OpenSSL pkgconfig or
>>> .la
>>> file or similar, which we inspect when building tcnative to learn about
>>> the
>>> correct flags to link against OpenSSL and APR.
>>>
>>> You might run
>>>
>>> find PATH -exec grep relro \{\} \; -ls
>>>
>>> with PATH replaced by the tcnative build directory and APR and OpenSSL
>>> install directories respectively. There are indications that debian adds
>>> the
>>> relro flag when building the system openssl.
>>>
>>> Does you linker understand "-z relro"? You can check "man ld" and "ld
>>> --help".
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>>>
>>> Am 25.04.2016 um 13:16 schrieb Stefan Frei:


 libapr1:amd64  1.5.1-3
 openssl1.0.1k-3+deb8u4

 2016-04-25 12:35 GMT+02:00 Mark Thomas :
>
>
> On 25/04/2016 10:31, Stefan Frei wrote:
>>
>>
>> Hello
>>
>> tomcat 8.0.33
>> tomcat-native-1.1.34-src
>> SMP Debian 3.16.7-ckt25-2
>> 1.8.0_77
>>
>> i am unable to compile the native libs, here is the error messages
>> from the make command:
>>
>> libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
>> libtool: link: `-Wl,-z,relro' is not valid version information
>> make[1]: *** [libtcnative-.la] Error 1
>> make: *** [all-recursive] Error 1
>>
>> I followed the instructions described here:
>> https://tomcat.apache.org/native-doc/
>>
>> how can i debug this?
>
>
>
> What versions of APR and OpenSSL are you compiling against?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leon,

On 4/22/16 12:24 PM, Leon Rosenberg wrote:
> Hi guys,
> 
> this is completely off-topic ;-)
> 
> I was wondering if using if/else is not actually slowing down your
> code. Lets say I have three possible conditions, A, B and C, which
> are exclusive. My native approach would be: if (A){...} if
> (B){...} if (C){...}
> 
> now some people would 'optimize' it as if (A){ ...} else if (B)
> {} else if (C) { } and I think in the world of single-cpu
> computers this optimization could work.
> 
> But what is now, given that compilers can optimize stuff like this
> and tell the processor to calculate all 3 branches simultaneously,
> which is not possible for ifelse.
> 
> Which one would you choose? Equally important, which one do you
> think is more readable? I would say if else is hard to read, but
> this can be just personal impression.

I would always choose the case with the elses.

First, I think it's more clear: if you expect that only one branch of
the code will run, and no others, then the elses tell the reader that
fact without any further commentary. The zero-else case might help you
catch some logic errors (because for example you can log each entry
into a branch) but there are of course other ways to do that.

Second, it's more efficient, regardless of what type of processor you
have. Let's take an example where there are more than 3 branches. How
about something like a million branches (just to accentuate the
point)? If one of the branches runs, the others are skipped. If all
branches have an equal change of being chosen, then the CPU has to
perform on average 50 predicates. If you put the common cases at
the top, you can do even better. Let's assume the 80/20 rule applies,
here, and you can take a guess that, on average, the CPU will only
have to perform 10 predicates on average.

In Java (specifically), if you can use a switch statement, it's
(sometimes) even better: Java has bytecode primitives for two kinds of
switches: "lookup" switches and "table" switches. The first is just a
big table of possible predicate values and the addresses of the target
branch. The CPU scans through the (sorted) table of values and then
jumps based upon what it found. If you have a big table, this can be
less efficient than if/elseif/elseif. The second is even better: the
value of the predicate can be used to compute the location in the
table, so no scanning is required.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlceJg8ACgkQ9CaO5/Lv0PAODQCfRCBvVgM2HSM2/CBEGtlBe0Pg
MrcAn2OdBYKJR0OSApcBFfONJHOlKGY0
=YeMH
-END PGP SIGNATURE-

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

Re: Small problems compiling tomcat native

[Rainer Jung]

Am 25.04.2016 um 14:31 schrieb Stefan Frei:

very sorry just solved it.


overlooked a line in configure

/root/tomcat-native-1.1.34-src/jni/native/build/get-version.sh:
Permission denied


OK, no problem. If extracted from a source tarball, the file should have 
been executable by default though. It might be it is not if you picked a 
zip file source download.


Another comment: OpenSSL 1.0.1k is pretty old. 1.0.1s is current for 
1.0.1 and even better would be 1.0.2g but it might be, that you won't 
find such a packet for your OS version. You could compile 1.0.2g 
yourself though and install in a separate directory. Using 1.0.2 you 
could switch to tcnative 1.2.x (which needs OpenSSL 1.0.2). The current 
tcnative 1.2.x is 1.2.5, but a 1.2.6 will likely be released during the 
next few days.


There are currently no plans for another tcnative 1.1.x release.

Regards,

Rainer


2016-04-25 14:04 GMT+02:00 Rainer Jung :

Can you provide the full configure command you use and the configure and
make output as well as config.log? Do you have environment variables set,
that influence the build (CC, CFLAGS, LDFLAGS or similar)?

The "-Wl,-z,relro" should not directly come from our own tcnative scripts
but using the make output (and configure output) we can double check.

It could be, that those flags come from and APR or OpenSSL pkgconfig or .la
file or similar, which we inspect when building tcnative to learn about the
correct flags to link against OpenSSL and APR.

You might run

find PATH -exec grep relro \{\} \; -ls

with PATH replaced by the tcnative build directory and APR and OpenSSL
install directories respectively. There are indications that debian adds the
relro flag when building the system openssl.

Does you linker understand "-z relro"? You can check "man ld" and "ld
--help".

Regards,

Rainer


Am 25.04.2016 um 13:16 schrieb Stefan Frei:


libapr1:amd64  1.5.1-3
openssl1.0.1k-3+deb8u4

2016-04-25 12:35 GMT+02:00 Mark Thomas :


On 25/04/2016 10:31, Stefan Frei wrote:


Hello

tomcat 8.0.33
tomcat-native-1.1.34-src
SMP Debian 3.16.7-ckt25-2
1.8.0_77

i am unable to compile the native libs, here is the error messages
from the make command:

libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
libtool: link: `-Wl,-z,relro' is not valid version information
make[1]: *** [libtcnative-.la] Error 1
make: *** [all-recursive] Error 1

I followed the instructions described here:
https://tomcat.apache.org/native-doc/

how can i debug this?



What versions of APR and OpenSSL are you compiling against?

Mark


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

Re: Small problems compiling tomcat native

[Stefan Frei]

very sorry just solved it.


overlooked a line in configure

/root/tomcat-native-1.1.34-src/jni/native/build/get-version.sh:
Permission denied

Regards Stefan

2016-04-25 14:04 GMT+02:00 Rainer Jung :
> Can you provide the full configure command you use and the configure and
> make output as well as config.log? Do you have environment variables set,
> that influence the build (CC, CFLAGS, LDFLAGS or similar)?
>
> The "-Wl,-z,relro" should not directly come from our own tcnative scripts
> but using the make output (and configure output) we can double check.
>
> It could be, that those flags come from and APR or OpenSSL pkgconfig or .la
> file or similar, which we inspect when building tcnative to learn about the
> correct flags to link against OpenSSL and APR.
>
> You might run
>
> find PATH -exec grep relro \{\} \; -ls
>
> with PATH replaced by the tcnative build directory and APR and OpenSSL
> install directories respectively. There are indications that debian adds the
> relro flag when building the system openssl.
>
> Does you linker understand "-z relro"? You can check "man ld" and "ld
> --help".
>
> Regards,
>
> Rainer
>
>
> Am 25.04.2016 um 13:16 schrieb Stefan Frei:
>>
>> libapr1:amd64  1.5.1-3
>> openssl1.0.1k-3+deb8u4
>>
>> 2016-04-25 12:35 GMT+02:00 Mark Thomas :
>>>
>>> On 25/04/2016 10:31, Stefan Frei wrote:

 Hello

 tomcat 8.0.33
 tomcat-native-1.1.34-src
 SMP Debian 3.16.7-ckt25-2
 1.8.0_77

 i am unable to compile the native libs, here is the error messages
 from the make command:

 libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
 libtool: link: `-Wl,-z,relro' is not valid version information
 make[1]: *** [libtcnative-.la] Error 1
 make: *** [all-recursive] Error 1

 I followed the instructions described here:
 https://tomcat.apache.org/native-doc/

 how can i debug this?
>>>
>>>
>>> What versions of APR and OpenSSL are you compiling against?
>>>
>>> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

Re: Small problems compiling tomcat native

[Rainer Jung]

Can you provide the full configure command you use and the configure and 
make output as well as config.log? Do you have environment variables 
set, that influence the build (CC, CFLAGS, LDFLAGS or similar)?


The "-Wl,-z,relro" should not directly come from our own tcnative 
scripts but using the make output (and configure output) we can double 
check.


It could be, that those flags come from and APR or OpenSSL pkgconfig or 
.la file or similar, which we inspect when building tcnative to learn 
about the correct flags to link against OpenSSL and APR.


You might run

find PATH -exec grep relro \{\} \; -ls

with PATH replaced by the tcnative build directory and APR and OpenSSL 
install directories respectively. There are indications that debian adds 
the relro flag when building the system openssl.


Does you linker understand "-z relro"? You can check "man ld" and "ld 
--help".


Regards,

Rainer

Am 25.04.2016 um 13:16 schrieb Stefan Frei:

libapr1:amd64  1.5.1-3
openssl1.0.1k-3+deb8u4

2016-04-25 12:35 GMT+02:00 Mark Thomas :

On 25/04/2016 10:31, Stefan Frei wrote:

Hello

tomcat 8.0.33
tomcat-native-1.1.34-src
SMP Debian 3.16.7-ckt25-2
1.8.0_77

i am unable to compile the native libs, here is the error messages
from the make command:

libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
libtool: link: `-Wl,-z,relro' is not valid version information
make[1]: *** [libtcnative-.la] Error 1
make: *** [all-recursive] Error 1

I followed the instructions described here:
https://tomcat.apache.org/native-doc/

how can i debug this?


What versions of APR and OpenSSL are you compiling against?

Mark


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

Re: Small problems compiling tomcat native

[Stefan Frei]

libapr1:amd64  1.5.1-3
openssl1.0.1k-3+deb8u4

2016-04-25 12:35 GMT+02:00 Mark Thomas :
> On 25/04/2016 10:31, Stefan Frei wrote:
>> Hello
>>
>> tomcat 8.0.33
>> tomcat-native-1.1.34-src
>> SMP Debian 3.16.7-ckt25-2
>> 1.8.0_77
>>
>> i am unable to compile the native libs, here is the error messages
>> from the make command:
>>
>> libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
>> libtool: link: `-Wl,-z,relro' is not valid version information
>> make[1]: *** [libtcnative-.la] Error 1
>> make: *** [all-recursive] Error 1
>>
>> I followed the instructions described here:
>> https://tomcat.apache.org/native-doc/
>>
>> how can i debug this?
>
> What versions of APR and OpenSSL are you compiling against?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

Re: Small problems compiling tomcat native

[Mark Thomas]

On 25/04/2016 10:31, Stefan Frei wrote:
> Hello
> 
> tomcat 8.0.33
> tomcat-native-1.1.34-src
> SMP Debian 3.16.7-ckt25-2
> 1.8.0_77
> 
> i am unable to compile the native libs, here is the error messages
> from the make command:
> 
> libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
> libtool: link: `-Wl,-z,relro' is not valid version information
> make[1]: *** [libtcnative-.la] Error 1
> make: *** [all-recursive] Error 1
> 
> I followed the instructions described here:
> https://tomcat.apache.org/native-doc/
> 
> how can i debug this?

What versions of APR and OpenSSL are you compiling against?

Mark


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

Small problems compiling tomcat native

[Stefan Frei]

Hello

tomcat 8.0.33
tomcat-native-1.1.34-src
SMP Debian 3.16.7-ckt25-2
1.8.0_77



i am unable to compile the native libs, here is the error messages
from the make command:

libtool: link: CURRENT `-Wl,-z,relro' must be a nonnegative integer
libtool: link: `-Wl,-z,relro' is not valid version information
make[1]: *** [libtcnative-.la] Error 1
make: *** [all-recursive] Error 1


I followed the instructions described here:
https://tomcat.apache.org/native-doc/



how can i debug this?


Best regards

Stefan

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

thread recovery

[Mahudeswaran A]

Hi All,
Let's assume mutex.wait being called in one of the tomcat thread.
The thread state is still RUNNABLE but the thread does nothing and just waiting.

Is there any functionality in tomcat to automatically recovery for these 
threads either through some configurations?
For e.g. if there are threads in the same state for more than 7 or 8 hours...

Thanks & Regards