You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Andy Wang <aw...@ptc.com> on 2013/05/02 18:52:57 UTC
Fwd: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so
(1.2.37) on iPlanet 7.0.15 an
WTF?!?!
-------- Original Message --------
Subject: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so
(1.2.37) on iPlanet 7.0.15 an
Date: Thu, 2 May 2013 12:50:01 -0400
From: PerfectGonzo Support <su...@support.perfectgonzo.com>
To: <aw...@ptc.com>
Dear Andy Wang,
A request for support has been created and assigned ticket #200250. We will answer you as soon as possible. If you wish to send additional comments or information regarding this issue, please reply to this email or login to the support website using your Email and Ticket Number: #200250 to add your additional comments.
Thank you,
PerfectGonzo Support
-----Your Ticket:-----
I'm redirecting this to the dev list. I hope that's okay as I think this
is a bit more appropriate for developers rather than users.
I got a response from Oracle finally.
@ When running as root, the provided priority of SYSTHREAD_DEFAULT_PRIORITY
@ gets cast to an NSPR value of PR_PRIORITY_URGENT, which is finally
mapped to
@ a native priority value of 85, which in turn happens to be outside the
@ allowed priority ranges as per system configuration. The provided priority
@ value is unused when running as non-root, and hence the issue is not seen.
@ .
@ In more detail:
@ .
@ This issue happens due to the specified thread priority falling
outside the
@ configured limits in the system. "priocntl -l" displays the priority
ranges
@ allowed:
@ .
@ ...
@ TS (Time Sharing)
@ Configured TS User Priority Range: -60 through 60
@ ...
@ .
@ The systhread_start() API internally calls NSPR's PR_CreateThread().
@ The value of SYSTHREAD_DEFAULT_PRIORITY is 16, and this is cast to the
NSPR
@ priority of PR_PRIORITY_URGENT.
@ .
@ PR_CreateThread() ultimately calls pthread_create(). Before doing so,
@ PR_CreateThread() updates the new thread's attributes with the provided
@ priority, and more importantly, this is done only if root privileges are
@ available. In the case of a non-root user, the provided priority is
not used.
@ .
@ Now the problem with PR_PRIORITY_URGENT is the following: NSPR maps
the same
@ to a native priority number (85) before using it to update the new
thread's
@ attributes. 85 is outside the allowed priority ranges as reported by
@ "priocntl -l", and hence the pthread_create() ends up failing.
@ .
@ The customer has the following options:
@ .
@ 1. Use PR_PRIORITY_LOW instead of SYSTHREAD_DEFAULT_PRIORITY.
@ PR_PRIORITY_NORMAL might work, too.
@ 2. Check with Solaris team on how to change the system configuration
to tweak
@ the allowed range of thread priorities
I've also confirmed that PR_PRIORITY_HIGH also fails but
PR_PRIORITY_NORMAL is fine.
I'm pushing oracle to accept that is is a bug. It is completely
inappropriate for what appears to be a perfectly proper constant,
SYSTHREAD_DEFAULT_PRIORITY, to map to something ilegal on Solaris 11.
Do you guys think this is worth a bugzilla report to track and consider
changing jk_nsapi_plugin.c to use the NSPR PR_PRIORITY_* values or is it
better to wait and see if Oracle fixes their code?
The response times I'm getting from them aren't great and they haven't
acknowledged my requests that this be considered a bug the 2 or 3 times
I've asked.
Andy
On 02/21/2013 04:14 PM, Andy Wang wrote:
> On 02/19/2013 11:13 AM, Rainer Jung wrote:
>> It will be tedious, but if we want to check whether the OS disallows
>> some syscalls when running as suid under root, then truss should provide
>> insight.
>>
>> So run iPlanet (the iPlanet start script) under truss -f -o
>> /some/path/tr.out once in the working config and once in the non-working
>> one and try to find differences w.r.t. to syscalls that return an error.
>>
>> Once you know what you are looking after, the additional truss flags "-v
>> all -w all -r all" will provide aditional insight (and a huge volume of
>> output).
>>
>>
> I was hoping to avoid truss and that someone else had experienced
> this, or had an idea of what might be new in Solaris 11 that would
> cause this :)
>
> This is in the case where it works:
> 8435/2: read(7, 0xFC1FDF50, 4096) Err#11 EAGAIN
> 8435/3: lwp_create() (returning as new lwp ...) = 0
> 8435/3: setustack(0xFC8D0AA0)
> 8435/3: schedctl() =
> 0xFC975020
> 8435/3: open("/etc/netconfig", O_RDONLY) = 13
> 8435/3: fstat64(13, 0xFC07F720) = 0
> 8435/3: fstat64(13, 0xFC07F630) = 0
>
> thread 3 was created and that's what does the systhread_start stuff.
>
> In the case where it doesn't work:
> 8207/2: read(8, 0xFC1FDF50, 4096) Err#11 EAGAIN
> 8205: pollsys(0x080B9008, 1, 0x080471D8, 0x00000000) = 1
> 8205: accept(4, 0x00000000, 0x00000000, SOV_DEFAULT) = 5
> 8192: waitid(P_ALL, 0, 0x080461D0,
> WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) (sleeping...)
> 8203: sigsuspend(0x08047220) (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/2: pollsys(0xFC1FDEB0, 1, 0xFC1FDE78, 0x00000000)
> (sleeping...)
> 8205: pollsys(0x080B9008, 2, 0x080471D8, 0x00000000) (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000)
> (sleeping...)
> 8207/1: pollsys(0x00000000, 0, 0x080427F8, 0x00000000) = 0
> 8207/2: pollsys(0xFC1FDEB0, 1, 0xFC1FDE78, 0x00000000) = 0
>
> So something is definitely preventing the systhread_start call to even
> get as far as the system call to lwp_create.
>
> Unfortunately, this is now quite a bit beyond me. Might have to
> figure out our partner contacts at oracle to see what's up.
>
> Andy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [OT] Re: java-server-socket-binding-multiple-domain-host-names
Posted by Elgs Qian Chen <el...@hotmail.com>.
Thanks Mark. Actually I have problem with Apache2 proxy module when the backend is a wesocket server. I have written my own TCP proxy/port mapper, however, it maps only one client to one server.
Now I think maybe I have to hack into the http protocol by reading a little bit from a client request, and steal out the server address information.
Yes, it's up to the DNS to translate the address, not the server itself. Thank you very much. Now I'm clear.
Best regards,
Elgs
Sent from my iPhone
On May 26, 2013, at 12:33 AM, "Mark Thomas" <ma...@apache.org> wrote:
> On 25/05/2013 17:23, Elgs Chen wrote:
>> Hi Mark,
>>
>> I'm very sorry I know this is not related to the Tomcat project.
>
> Then mark the thread as off-topic and use the users mailing list.
>
>> However, I cannot find anyone who I think has more expertise in java networking programming than you.
>
> Then you need to get out more. Also, flattery will get you nowhere.
>
>> I have a java server socket problem and I have no way to find the answer. I'm really hoping I can get some insights from you. Thanks in advance.
>>
>> And here's the URL to this question:
>> http://stackoverflow.com/questions/16751062/java-server-socket-binding-multiple-domain-host-names
>
> Try reading the perfectly good answer you have already received or,
> better yet, stop and think exactly what it is DNS does.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[OT] Re: java-server-socket-binding-multiple-domain-host-names
Posted by Mark Thomas <ma...@apache.org>.
On 25/05/2013 17:23, Elgs Chen wrote:
> Hi Mark,
>
> I'm very sorry I know this is not related to the Tomcat project.
Then mark the thread as off-topic and use the users mailing list.
> However, I cannot find anyone who I think has more expertise in java networking programming than you.
Then you need to get out more. Also, flattery will get you nowhere.
> I have a java server socket problem and I have no way to find the answer. I'm really hoping I can get some insights from you. Thanks in advance.
>
> And here's the URL to this question:
> http://stackoverflow.com/questions/16751062/java-server-socket-binding-multiple-domain-host-names
Try reading the perfectly good answer you have already received or,
better yet, stop and think exactly what it is DNS does.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: java-server-socket-binding-multiple-domain-host-names
Posted by Elgs Chen <el...@hotmail.com>.
Yes, .getLocalAddress().getHostName() is not reliable. I don't assume the connection to be an HTTP connection. Probably I will set a new flag like allowPeep: true to request peeping into the header information if the users know that they are using HTTP for this connection. However, I'm afraid it's not possible to peep if the users are using HTTPS.
Thanks for the info, Enrico.
Elgs
On May 26, 2013, at 2:43 AM, Enrico Olivelli <eo...@gmail.com> wrote:
> If you are using HTTP then clients will politely tell you which DNS name they are tryning to connect to using the "host:" header.
> TCP does not give any info about "hostnames", but only about "IP Addresses"
> I think .getLocalAddress().getHostName() will simply try to resolve back the IP address to a DNS name
>
> I hope that helps
> Enrico
>
> Il 25/05/2013 18:23, Elgs Chen ha scritto:
>> Hi Mark,
>>
>> I'm very sorry I know this is not related to the Tomcat project. However, I cannot find anyone who I think has more expertise in java networking programming than you.
>>
>> I have a java server socket problem and I have no way to find the answer. I'm really hoping I can get some insights from you. Thanks in advance.
>>
>> And here's the URL to this question:
>> http://stackoverflow.com/questions/16751062/java-server-socket-binding-multiple-domain-host-names
>>
>> I have a java nio server with ip address 192.168.0.1 listening on port 80. I configured this server to bind to multiple domain/host names, let's say server1, server2, server3 are all resolved as 192.168.0.1.
>>
>> Now I'm hoping if the client connects to server1, on the server side, I can recognize that the client is connecting to server1 instead of other names or direct ip address, so that I can do something special, and if the client is connecting to server2, I can recognize that the client is requesting server2, so I can do something else special, and so on.
>>
>> Now the question is: seems on the server side, I cannot easily get the correct information which server name my clients are connecting to.
>>
>> I have the follow code:
>>
>> ServerSocketChannel ssChannel = (ServerSocketChannel) selKey.channel();
>> String boundHost = sChannel.socket().getLocalAddress().getHostName();
>> But it does not work, the boundHost is always the server1 even if clients connect to server2 or server3.
>>
>> Thanks,
>> Elgs
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: java-server-socket-binding-multiple-domain-host-names
Posted by Enrico Olivelli <eo...@gmail.com>.
If you are using HTTP then clients will politely tell you which DNS name
they are tryning to connect to using the "host:" header.
TCP does not give any info about "hostnames", but only about "IP Addresses"
I think .getLocalAddress().getHostName() will simply try to resolve back
the IP address to a DNS name
I hope that helps
Enrico
Il 25/05/2013 18:23, Elgs Chen ha scritto:
> Hi Mark,
>
> I'm very sorry I know this is not related to the Tomcat project. However, I cannot find anyone who I think has more expertise in java networking programming than you.
>
> I have a java server socket problem and I have no way to find the answer. I'm really hoping I can get some insights from you. Thanks in advance.
>
> And here's the URL to this question:
> http://stackoverflow.com/questions/16751062/java-server-socket-binding-multiple-domain-host-names
>
> I have a java nio server with ip address 192.168.0.1 listening on port 80. I configured this server to bind to multiple domain/host names, let's say server1, server2, server3 are all resolved as 192.168.0.1.
>
> Now I'm hoping if the client connects to server1, on the server side, I can recognize that the client is connecting to server1 instead of other names or direct ip address, so that I can do something special, and if the client is connecting to server2, I can recognize that the client is requesting server2, so I can do something else special, and so on.
>
> Now the question is: seems on the server side, I cannot easily get the correct information which server name my clients are connecting to.
>
> I have the follow code:
>
> ServerSocketChannel ssChannel = (ServerSocketChannel) selKey.channel();
> String boundHost = sChannel.socket().getLocalAddress().getHostName();
> But it does not work, the boundHost is always the server1 even if clients connect to server2 or server3.
>
> Thanks,
> Elgs
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
java-server-socket-binding-multiple-domain-host-names
Posted by Elgs Chen <el...@hotmail.com>.
Hi Mark,
I'm very sorry I know this is not related to the Tomcat project. However, I cannot find anyone who I think has more expertise in java networking programming than you.
I have a java server socket problem and I have no way to find the answer. I'm really hoping I can get some insights from you. Thanks in advance.
And here's the URL to this question:
http://stackoverflow.com/questions/16751062/java-server-socket-binding-multiple-domain-host-names
I have a java nio server with ip address 192.168.0.1 listening on port 80. I configured this server to bind to multiple domain/host names, let's say server1, server2, server3 are all resolved as 192.168.0.1.
Now I'm hoping if the client connects to server1, on the server side, I can recognize that the client is connecting to server1 instead of other names or direct ip address, so that I can do something special, and if the client is connecting to server2, I can recognize that the client is requesting server2, so I can do something else special, and so on.
Now the question is: seems on the server side, I cannot easily get the correct information which server name my clients are connecting to.
I have the follow code:
ServerSocketChannel ssChannel = (ServerSocketChannel) selKey.channel();
String boundHost = sChannel.socket().getLocalAddress().getHostName();
But it does not work, the boundHost is always the server1 even if clients connect to server2 or server3.
Thanks,
Elgs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so
(1.2.37) on iPlanet 7.0.15 an
Posted by Mark Thomas <ma...@apache.org>.
On 02/05/2013 17:59, Caldarale, Charles R wrote:
>> From: Andy Wang [mailto:awang@ptc.com]
>> Subject: Fwd: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 an
>
>> WTF?!?!
>
>> -------- Original Message --------
>> Subject: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so
>> (1.2.37) on iPlanet 7.0.15 an
>> Date: Thu, 2 May 2013 12:50:01 -0400
>> From: PerfectGonzo Support <su...@support.perfectgonzo.com>
>> To: <aw...@ptc.com>
>
> I think you've found a candidate company to forcibly remove from the mailing list...
The problem is that they aren't subscribed. I've been through the logs
and can find no record of them subscribing.
Some idiot is forwarding to them - the problem is I don't know which idiot.
/me Has an idea.
I might be able to figure out who the idiot is. Let me work on it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so
(1.2.37) on iPlanet 7.0.15 an
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Andy Wang [mailto:awang@ptc.com]
> Subject: Fwd: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so (1.2.37) on iPlanet 7.0.15 an
> WTF?!?!
> -------- Original Message --------
> Subject: Support Ticket [#200250] - Re: Problem with nsapi_redirect.so
> (1.2.37) on iPlanet 7.0.15 an
> Date: Thu, 2 May 2013 12:50:01 -0400
> From: PerfectGonzo Support <su...@support.perfectgonzo.com>
> To: <aw...@ptc.com>
I think you've found a candidate company to forcibly remove from the mailing list...
- 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org