Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] grouper web service problems - grouper 2.1.1

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] grouper web service problems - grouper 2.1.1


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Lynn Garrison <>
  • Cc: Grouper Dev <>
  • Subject: RE: [grouper-dev] grouper web service problems - grouper 2.1.1
  • Date: Sun, 12 Aug 2012 21:30:17 +0000
  • Accept-language: en-US

Ok, there was a suggestion from someone to change the axis2.xml so that it would work with SSL, but it had a side effect that it would cause axis to listen on 8443.  So if you change the axis2.xml in the following was it will fix this so it works with SSL and doesn’t listen on 8443.  I don’t know what you can do with the 8443 port, if its not behind a firewall you might want to make this change so that WS doesn’t listen on that port for security reasons.

 

https://bugs.internet2.edu/jira/browse/GRP-819

 

FROM:

 

 

    <transportReceiver name="http"

                       class="org.apache.axis2.transport.http.SimpleHTTPServer">

        <parameter name="port" locked="false">8080</parameter>

        <!-- Here is the complete list of supported parameters (see example settings further below):

            port: the port to listen on (default 6060)

            hostname: if non-null, url prefix used in reply-to endpoint references (default null)

            originServer: value of http Server header in outgoing messages (default "Simple-Server/1.1")

            requestTimeout: value in millis of time that requests can wait for data (default 20000)

            requestTcpNoDelay: true to maximize performance and minimize latency (default true)

                                false to minimize bandwidth consumption by combining segments

            requestCoreThreadPoolSize: number of threads available for request processing (unless queue fills up) (default 25)

            requestMaxThreadPoolSize: number of threads available for request processing if queue fills up (default 150)

                                       note that default queue never fills up: see HttpFactory

            threadKeepAliveTime: time to keep threads in excess of core size alive while inactive (default 180)

                                  note that no such threads can exist with default unbounded request queue

            threadKeepAliveTimeUnit: TimeUnit of value in threadKeepAliveTime (default SECONDS) (default SECONDS)

        -->

        <!-- <parameter name="hostname">http://www.myApp.com/ws&lt;/parameter> -->

        <!-- <parameter name="originServer">My-Server/1.1</parameter> -->

        <!-- <parameter name="requestTimeout">10000</parameter> -->

        <!-- <parameter name="requestTcpNoDelay">false</parameter> -->

        <!-- <parameter name="requestCoreThreadPoolSize">50</parameter> -->

        <!-- <parameter name="requestMaxThreadPoolSize">100</parameter> -->

        <!-- <parameter name="threadKeepAliveTime">240000</parameter> -->

        <!-- <parameter name="threadKeepAliveTimeUnit">MILLISECONDS</parameter> -->

    </transportReceiver>

 

    <transportReceiver name="https"

                       class="org.apache.axis2.transport.http.SimpleHTTPServer">

        <parameter name="port" locked="false">8443</parameter>

        <!-- Here is the complete list of supported parameters (see example settings further below):

            port: the port to listen on (default 6060)

            hostname: if non-null, url prefix used in reply-to endpoint references (default null)

            originServer: value of http Server header in outgoing messages (default "Simple-Server/1.1")

            requestTimeout: value in millis of time that requests can wait for data (default 20000)

            requestTcpNoDelay: true to maximize performance and minimize latency (default true)

                                false to minimize bandwidth consumption by combining segments

            requestCoreThreadPoolSize: number of threads available for request processing (unless queue fills up) (default 25)

            requestMaxThreadPoolSize: number of threads available for request processing if queue fills up (default 150)

                                       note that default queue never fills up: see HttpFactory

            threadKeepAliveTime: time to keep threads in excess of core size alive while inactive (default 180)

                                  note that no such threads can exist with default unbounded request queue

            threadKeepAliveTimeUnit: TimeUnit of value in threadKeepAliveTime (default SECONDS) (default SECONDS)

        -->

        <!-- <parameter name="hostname">http://www.myApp.com/ws&lt;/parameter> -->

        <!-- <parameter name="originServer">My-Server/1.1</parameter> -->

        <!-- <parameter name="requestTimeout">10000</parameter> -->

        <!-- <parameter name="requestTcpNoDelay">false</parameter> -->

        <!-- <parameter name="requestCoreThreadPoolSize">50</parameter> -->

        <!-- <parameter name="requestMaxThreadPoolSize">100</parameter> -->

        <!-- <parameter name="threadKeepAliveTime">240000</parameter> -->

        <!-- <parameter name="threadKeepAliveTimeUnit">MILLISECONDS</parameter> -->

    </transportReceiver>

 

TO:

 

 

    <transportReceiver name="http" class="org.apache.axis2.transport.http.AxisServletListener">

      <parameter name="port">8080</parameter>

    </transportReceiver>

 

    <transportReceiver name="https" class="org.apache.axis2.transport.http.AxisServletListener">

      <parameter name="port">443</parameter>

    </transportReceiver>

 

This is fixed in 2.1.2, though you can change your axis2.xml and bounce the servlet container to fix any version of grouper with this issue.

 

Thanks,

Chris

 

 

From: [mailto:] On Behalf Of Chris Hyzer
Sent: Friday, July 13, 2012 11:42 AM
To: Lynn Garrison
Cc: Grouper Dev
Subject: RE: [grouper-dev] grouper web service problems - grouper 2.1.1

 

Then something else is probably using one of the tomcat ports… what ports is tomcat configured to use (server.xml), and netstat those, see which is in use, and change it to something else in server.xml…

 

Thanks,

Chris

 

From: Lynn Garrison []
Sent: Friday, July 13, 2012 11:38 AM
To: Chris Hyzer
Cc: Grouper Dev
Subject: Re: [grouper-dev] grouper web service problems - grouper 2.1.1

 

Chris,

                        Tomcat  is definitely stopped.  We don't use the standard stop scripts for tomcat.  The script we use executes a kill -9 on the tomcat process.  Also we get the same error when  tomcat starts after a reboot of the machine.

 

 

On Jul 13, 2012, at 11:28 AM, Chris Hyzer wrote:

 

That means tomcat didn't stop completely, right?  Stop tomcat.  Check the process and if it is still running or something is listening on the port, then kill the process until it is dead and nothing is listening on the port, then start.  At Penn our tomcat stop script checks to make sure it is really dead and not just asked to die.

Thanks,
Chris

-----Original Message-----
From: [] On Behalf Of Lynn Garrison
Sent: Friday, July 13, 2012 11:26 AM
To: Grouper Dev
Subject: [grouper-dev] grouper web service problems - grouper 2.1.1

            I have  successfully installed and tested  grouper 2.1.1 on our test environment.     When I installed the grouper web service war on our acceptance machine I get the following error:


2012-07-13 11:17:30,916: [HttpListener-8443-1] ERROR DefaultConnectionListenerFailureHandler.notifyAbnormalTermination(102) -  - Terminating connection listener after 10retries in 0 seconds.
java.net.BindException: Address already in use
            at java.net.PlainSocketImpl.socketBind(Native Method)
            at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:353)
            at java.net.ServerSocket.bind(ServerSocket.java:336)
            at java.net.ServerSocket.<init>(ServerSocket.java:202)
            at java.net.ServerSocket.<init>(ServerSocket.java:114)
            at org.apache.axis2.transport.http.server.DefaultConnectionListener.run(DefaultConnectionListener.java:80)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
            at java.lang.Thread.run(Thread.java:679)


            We manage the two environments by making all the required changes on the test machine, test all the applications and then rsync the grouper directory to the acceptance machine.  Minimal change (database connection and grouper.ui.url) are made in the grouper configuration on the acceptance machine.  The ui and ws  war files are rebuilt and installed in the tomcat web apps directory.  


Lynn

 

Lynn

 



  • RE: [grouper-dev] grouper web service problems - grouper 2.1.1, Chris Hyzer, 08/12/2012

Archive powered by MHonArc 2.6.16.

Top of Page