Advise on hosting

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Issue with ssl call

Sebastian Esch
The easiest way would be to use the server name
svcs.sandbox.paypal.com for the connection. Then the validation of the
certificat will not fail. Or is there a particular reason why you use
the IP address?

Cheers,
Sebastian

On Wed, Feb 9, 2011 at 7:35 PM, Peter Bell <[hidden email]> wrote:

> I know it's kind of a long shot, but I'm still wrangling with the Paypal
> adaptive payments API. I moved from my own implementation using http-builder
> to a java SDK (https://www.x.com/community/ppx/sdks#ADAPI) , but I'm getting
> the same error:
> Error 500: Executing action [purchase] of controller
> [com.clientName.EventController] caused exception:
> com.paypal.platform.sdk.exception.FatalException: hostname in certificate
> didn't match: <216.113.191.96> != <svcs.sandbox.paypal.com>
> The FatalException is just a catch/rethrow going on in the Paypal SDK for an
> underlying connection error.  The error I was getting before was
> a javax.net.ssl.SSLException with the same message string, so I'm guessing
> that's still the underlying error.
> Just wondering if anyone has any first level thoughts on how to go about
> handling this?
> Best Wishes,
> Peter
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Issue with ssl call

Peter Bell-5
The strange thing is I *am* using the server name for the connection. I tried this using an http-builder myself and then rewrote using the Paypal SDK (as I figured I was just "not getting" something to do with the headers required or similar). In both cases I pass in the target destination of https://svcs.sandbox.paypal.com/AdaptivePayments/Pay and I get back the error below.

And FWIW, same error on the production servers (https://svcs.paypal.com/AdaptivePayments/Pay) so it isn't just something simple like the sandbox being misconfigured.

Also, tried without the s just in case I could http:// - at least in the sandbox, but it didn't accept the connection.

Best Wishes,
Peter


On Feb 9, 2011, at 1:49 PM, Sebastian Esch wrote:

> The easiest way would be to use the server name
> svcs.sandbox.paypal.com for the connection. Then the validation of the
> certificat will not fail. Or is there a particular reason why you use
> the IP address?
>
> Cheers,
> Sebastian
>
> On Wed, Feb 9, 2011 at 7:35 PM, Peter Bell <[hidden email]> wrote:
>> I know it's kind of a long shot, but I'm still wrangling with the Paypal
>> adaptive payments API. I moved from my own implementation using http-builder
>> to a java SDK (https://www.x.com/community/ppx/sdks#ADAPI) , but I'm getting
>> the same error:
>> Error 500: Executing action [purchase] of controller
>> [com.clientName.EventController] caused exception:
>> com.paypal.platform.sdk.exception.FatalException: hostname in certificate
>> didn't match: <216.113.191.96> != <svcs.sandbox.paypal.com>
>> The FatalException is just a catch/rethrow going on in the Paypal SDK for an
>> underlying connection error.  The error I was getting before was
>> a javax.net.ssl.SSLException with the same message string, so I'm guessing
>> that's still the underlying error.
>> Just wondering if anyone has any first level thoughts on how to go about
>> handling this?
>> Best Wishes,
>> Peter
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Issue with ssl call

Sebastian Esch
What's your environment (OS, AppServer)? It seems strange that the IP
address is not resolved to the host name.

Did you try to resolve the hostname from a shell?


On Wed, Feb 9, 2011 at 9:35 PM, Peter Bell <[hidden email]> wrote:

> The strange thing is I *am* using the server name for the connection. I tried this using an http-builder myself and then rewrote using the Paypal SDK (as I figured I was just "not getting" something to do with the headers required or similar). In both cases I pass in the target destination of https://svcs.sandbox.paypal.com/AdaptivePayments/Pay and I get back the error below.
>
> And FWIW, same error on the production servers (https://svcs.paypal.com/AdaptivePayments/Pay) so it isn't just something simple like the sandbox being misconfigured.
>
> Also, tried without the s just in case I could http:// - at least in the sandbox, but it didn't accept the connection.
>
> Best Wishes,
> Peter
>
>
> On Feb 9, 2011, at 1:49 PM, Sebastian Esch wrote:
>
>> The easiest way would be to use the server name
>> svcs.sandbox.paypal.com for the connection. Then the validation of the
>> certificat will not fail. Or is there a particular reason why you use
>> the IP address?
>>
>> Cheers,
>> Sebastian
>>
>> On Wed, Feb 9, 2011 at 7:35 PM, Peter Bell <[hidden email]> wrote:
>>> I know it's kind of a long shot, but I'm still wrangling with the Paypal
>>> adaptive payments API. I moved from my own implementation using http-builder
>>> to a java SDK (https://www.x.com/community/ppx/sdks#ADAPI) , but I'm getting
>>> the same error:
>>> Error 500: Executing action [purchase] of controller
>>> [com.clientName.EventController] caused exception:
>>> com.paypal.platform.sdk.exception.FatalException: hostname in certificate
>>> didn't match: <216.113.191.96> != <svcs.sandbox.paypal.com>
>>> The FatalException is just a catch/rethrow going on in the Paypal SDK for an
>>> underlying connection error.  The error I was getting before was
>>> a javax.net.ssl.SSLException with the same message string, so I'm guessing
>>> that's still the underlying error.
>>> Just wondering if anyone has any first level thoughts on how to go about
>>> handling this?
>>> Best Wishes,
>>> Peter
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Issue with ssl call

Sebastian Esch
https://issues.apache.org/jira/browse/HTTPCLIENT-996 sounds like what
you are seeing. Any chance that your http-builder version is using
Apache HTTP-Client 4.0.2?

On Wed, Feb 9, 2011 at 10:20 PM, Sebastian Esch
<[hidden email]> wrote:

> What's your environment (OS, AppServer)? It seems strange that the IP
> address is not resolved to the host name.
>
> Did you try to resolve the hostname from a shell?
>
>
> On Wed, Feb 9, 2011 at 9:35 PM, Peter Bell <[hidden email]> wrote:
>> The strange thing is I *am* using the server name for the connection. I tried this using an http-builder myself and then rewrote using the Paypal SDK (as I figured I was just "not getting" something to do with the headers required or similar). In both cases I pass in the target destination of https://svcs.sandbox.paypal.com/AdaptivePayments/Pay and I get back the error below.
>>
>> And FWIW, same error on the production servers (https://svcs.paypal.com/AdaptivePayments/Pay) so it isn't just something simple like the sandbox being misconfigured.
>>
>> Also, tried without the s just in case I could http:// - at least in the sandbox, but it didn't accept the connection.
>>
>> Best Wishes,
>> Peter
>>
>>
>> On Feb 9, 2011, at 1:49 PM, Sebastian Esch wrote:
>>
>>> The easiest way would be to use the server name
>>> svcs.sandbox.paypal.com for the connection. Then the validation of the
>>> certificat will not fail. Or is there a particular reason why you use
>>> the IP address?
>>>
>>> Cheers,
>>> Sebastian
>>>
>>> On Wed, Feb 9, 2011 at 7:35 PM, Peter Bell <[hidden email]> wrote:
>>>> I know it's kind of a long shot, but I'm still wrangling with the Paypal
>>>> adaptive payments API. I moved from my own implementation using http-builder
>>>> to a java SDK (https://www.x.com/community/ppx/sdks#ADAPI) , but I'm getting
>>>> the same error:
>>>> Error 500: Executing action [purchase] of controller
>>>> [com.clientName.EventController] caused exception:
>>>> com.paypal.platform.sdk.exception.FatalException: hostname in certificate
>>>> didn't match: <216.113.191.96> != <svcs.sandbox.paypal.com>
>>>> The FatalException is just a catch/rethrow going on in the Paypal SDK for an
>>>> underlying connection error.  The error I was getting before was
>>>> a javax.net.ssl.SSLException with the same message string, so I'm guessing
>>>> that's still the underlying error.
>>>> Just wondering if anyone has any first level thoughts on how to go about
>>>> handling this?
>>>> Best Wishes,
>>>> Peter
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Issue with ssl call

Peter Bell-5
Hmmm,

It does look like the error I'm getting. 

I'm on OSX (10.6.6), Groovy Version: 1.8.0-beta-2 JVM: 1.6.0_22. (I know I should upload Groovy but I don't think that's the issue). 

Project dependencies for http-builder includes 4.0.1 (http://groovy.codehaus.org/modules/http-builder/dependencies.html)

I don't have a file called httpcore-4.0.2.jar on my machine anywhere (search in Finder)

When I run grails dependency-report, nothing related to the httpcore file comes up at all. 

But, when I explicitly put 4.0.1 into my lib directory, the error goes away. 

Wow - Sebastian - many thanks! That was it. Much appreciated!

Best Wishes,
Peter


On Feb 9, 2011, at 4:41 PM, Sebastian Esch wrote:

https://issues.apache.org/jira/browse/HTTPCLIENT-996 sounds like what
you are seeing. Any chance that your http-builder version is using
Apache HTTP-Client 4.0.2?

On Wed, Feb 9, 2011 at 10:20 PM, Sebastian Esch
<[hidden email]> wrote:
What's your environment (OS, AppServer)? It seems strange that the IP
address is not resolved to the host name.

Did you try to resolve the hostname from a shell?


On Wed, Feb 9, 2011 at 9:35 PM, Peter Bell <[hidden email]> wrote:
The strange thing is I *am* using the server name for the connection. I tried this using an http-builder myself and then rewrote using the Paypal SDK (as I figured I was just "not getting" something to do with the headers required or similar). In both cases I pass in the target destination of https://svcs.sandbox.paypal.com/AdaptivePayments/Pay and I get back the error below.

And FWIW, same error on the production servers (https://svcs.paypal.com/AdaptivePayments/Pay) so it isn't just something simple like the sandbox being misconfigured.

Also, tried without the s just in case I could http:// - at least in the sandbox, but it didn't accept the connection.

Best Wishes,
Peter


On Feb 9, 2011, at 1:49 PM, Sebastian Esch wrote:

The easiest way would be to use the server name
svcs.sandbox.paypal.com for the connection. Then the validation of the
certificat will not fail. Or is there a particular reason why you use
the IP address?

Cheers,
Sebastian

On Wed, Feb 9, 2011 at 7:35 PM, Peter Bell <[hidden email]> wrote:
I know it's kind of a long shot, but I'm still wrangling with the Paypal
adaptive payments API. I moved from my own implementation using http-builder
to a java SDK (https://www.x.com/community/ppx/sdks#ADAPI) , but I'm getting
the same error:
Error 500: Executing action [purchase] of controller
[com.clientName.EventController] caused exception:
com.paypal.platform.sdk.exception.FatalException: hostname in certificate
didn't match: <216.113.191.96> != <svcs.sandbox.paypal.com>
The FatalException is just a catch/rethrow going on in the Paypal SDK for an
underlying connection error.  The error I was getting before was
a javax.net.ssl.SSLException with the same message string, so I'm guessing
that's still the underlying error.
Just wondering if anyone has any first level thoughts on how to go about
handling this?
Best Wishes,
Peter


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Advise on hosting

lucastex
In reply to this post by bkane
You can solve this in two ways:

=== First way - Do not use JNDI (recommended by Beanstalk and AWS) ===

The 'de facto' solution of one war running on multiple beanstalk environments is to use the system property "JDBC_CONNECTION_STRING".
You would configure it with your database url and use in your datasources.groovy like this

production {

        dataSource {
           
            username = "rds_user"
            password ="rds_password"
            url = System.getProperty("JDBC_CONNECTION_STRING")
        }
}

In beanstalk configuration, it allows you to configure more 5 extra parameters (PARAM1, PARAM2, PARAM3, PARAM4, PARAM5).
Unfortunately, you can't change the param names, but in my case, I'm using PARAM1 for username and PARAM2 for password, so, my dataSource closure is like this:

production {

        dataSource {
           
            username = System.getProperty("PARAM1")
            password =System.getProperty("PARAM2")
            url = System.getProperty("JDBC_CONNECTION_STRING")
        }
}

=== Second way - with JNDI ===

If you really want to use JNDI, you'll have to configure it on the Beanstalk Tomcat. The problem is that when beanstalk starts more instances due load on your environment (based on your AutoScaling configuration), the new instance will use a fresh tomcat, and will not have your configured JNDIs.

The solution, if you dont want to leave JNDI, is to use the AMI (Machine Image) that Beanstalk uses, and based on it, configure another AMI just for you, with your configuration (jndi conf). After that, you can set your environment to use your AMI instead of Beanstalk default AMI.

I really recommend you going on the first way :)

[]s,


Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Wed, Feb 9, 2011 at 3:38 PM, Brandon Kane <[hidden email]> wrote:
Our app is currently using a jndi lookup to get the datasource, so the pooling, etc is done by Tomcat.  What is the right way to use this property in Grails/AWS/RDS so that I can have one war file to deploy to multiple environments?


On Wed, Feb 9, 2011 at 10:06 AM, Peter Ledbrook <[hidden email]> wrote:
> Beanstalk provides you a automatically added to your tomcat system variable
> JDBC_CONNECTION_STRING, that you can use in your code:
>
> jdbcUrl = System.getProperty("JDBC_CONNECTION_STRING")

Gah! They keep referring to it as an environment variable, so I was
using System.getenv(). No wonder that wasn't working.

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Advise on hosting

Wolfgang Schell
Lucas F. A. Teixeira wrote
*=== Second way - with JNDI ===*

If you really want to use JNDI, you'll have to configure it on the Beanstalk
Tomcat. The problem is that when beanstalk starts more instances due load on
your environment (based on your AutoScaling configuration), the new instance
will use a fresh tomcat, and will not have your configured JNDIs.

The solution, if you dont want to leave JNDI, is to use the AMI (Machine
Image) that Beanstalk uses, and based on it, configure another AMI just for
you, with your configuration (jndi conf). After that, you can set your
environment to use your AMI instead of Beanstalk default AMI.

I really recommend you going on the first way :)
If you want to go the second way and create a customized AMI, I created a write-up on necessary steps (excluding setting JNDI-Params). See http://blog.jetztgrad.net/2011/02/how-to-customize-an-amazon-elastic-beanstalk-instance/

Regards,

Wolfgang
Reply | Threaded
Open this post in threaded view
|

Re: Advise on hosting

lucastex
Excellent writing!

I didn't know was so easy as this!
This can solve many other problems like installing memcached, terracotta and other stuff!

Thanks Wolfgang!


Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Wed, Feb 9, 2011 at 10:08 PM, Wolfgang Schell <[hidden email]> wrote:


Lucas F. A. Teixeira wrote:
>
> *=== Second way - with JNDI ===*
>
> If you really want to use JNDI, you'll have to configure it on the
> Beanstalk
> Tomcat. The problem is that when beanstalk starts more instances due load
> on
> your environment (based on your AutoScaling configuration), the new
> instance
> will use a fresh tomcat, and will not have your configured JNDIs.
>
> The solution, if you dont want to leave JNDI, is to use the AMI (Machine
> Image) that Beanstalk uses, and based on it, configure another AMI just
> for
> you, with your configuration (jndi conf). After that, you can set your
> environment to use your AMI instead of Beanstalk default AMI.
>
> I really recommend you going on the first way :)
>

If you want to go the second way and create a customized AMI, I created a
write-up on necessary steps (excluding setting JNDI-Params). See
http://blog.jetztgrad.net/2011/02/how-to-customize-an-amazon-elastic-beanstalk-instance/

Regards,

Wolfgang
--
View this message in context: http://grails.1312388.n4.nabble.com/Advise-on-hosting-tp3276494p3298368.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Advise on hosting

bkane
In reply to this post by lucastex
Thanks for the details!  I will take a look at Wolfgang's post as well on the AMIs, thanks for that.

Are there any concerns with connection pooling when just using the default data source settings like this?  I'm not tied to JNDI lookups, just used to that from back in the old Java days of supporting WebLogic, WebSphere, Oracle AS, where all the pooling settings were different and the only way to have one app deploy across all of them was leave the DS management to the container and just look it up via JNDI.



On Wed, Feb 9, 2011 at 6:18 PM, Lucas F. A. Teixeira <[hidden email]> wrote:
You can solve this in two ways:

=== First way - Do not use JNDI (recommended by Beanstalk and AWS) ===

The 'de facto' solution of one war running on multiple beanstalk environments is to use the system property "JDBC_CONNECTION_STRING".
You would configure it with your database url and use in your datasources.groovy like this

production {

        dataSource {
           
            username = "rds_user"
            password ="rds_password"

            url = System.getProperty("JDBC_CONNECTION_STRING")
        }
}

In beanstalk configuration, it allows you to configure more 5 extra parameters (PARAM1, PARAM2, PARAM3, PARAM4, PARAM5).
Unfortunately, you can't change the param names, but in my case, I'm using PARAM1 for username and PARAM2 for password, so, my dataSource closure is like this:

production {

        dataSource {
           
            username = System.getProperty("PARAM1")
            password =System.getProperty("PARAM2")

            url = System.getProperty("JDBC_CONNECTION_STRING")
        }
}

=== Second way - with JNDI ===

If you really want to use JNDI, you'll have to configure it on the Beanstalk Tomcat. The problem is that when beanstalk starts more instances due load on your environment (based on your AutoScaling configuration), the new instance will use a fresh tomcat, and will not have your configured JNDIs.

The solution, if you dont want to leave JNDI, is to use the AMI (Machine Image) that Beanstalk uses, and based on it, configure another AMI just for you, with your configuration (jndi conf). After that, you can set your environment to use your AMI instead of Beanstalk default AMI.

I really recommend you going on the first way :)
On Wed, Feb 9, 2011 at 3:38 PM, Brandon Kane <[hidden email]> wrote:
Our app is currently using a jndi lookup to get the datasource, so the pooling, etc is done by Tomcat.  What is the right way to use this property in Grails/AWS/RDS so that I can have one war file to deploy to multiple environments?


On Wed, Feb 9, 2011 at 10:06 AM, Peter Ledbrook <[hidden email]> wrote:
> Beanstalk provides you a automatically added to your tomcat system variable
> JDBC_CONNECTION_STRING, that you can use in your code:
>
> jdbcUrl = System.getProperty("JDBC_CONNECTION_STRING")

Gah! They keep referring to it as an environment variable, so I was
using System.getenv(). No wonder that wasn't working.

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|

Re: Advise on hosting

lucastex
When you have a clustered environment, and a datasource pointing to it, the datasource config will be applied and shared to all servers (max_connections, and other stuff).

But if you don't have a clustered env, just tomcats, won't be too much different if they connect using a jdni datasource or directly the connection, cause it'll be applied by node.

[]s,



Lucas Frare Teixeira .·.
- [hidden email]
- lucastex.com.br
- blog.lucastex.com
- twitter.com/lucastex


On Thu, Feb 10, 2011 at 3:00 AM, Brandon Kane <[hidden email]> wrote:
Thanks for the details!  I will take a look at Wolfgang's post as well on the AMIs, thanks for that.

Are there any concerns with connection pooling when just using the default data source settings like this?  I'm not tied to JNDI lookups, just used to that from back in the old Java days of supporting WebLogic, WebSphere, Oracle AS, where all the pooling settings were different and the only way to have one app deploy across all of them was leave the DS management to the container and just look it up via JNDI.



On Wed, Feb 9, 2011 at 6:18 PM, Lucas F. A. Teixeira <[hidden email]> wrote:
You can solve this in two ways:

=== First way - Do not use JNDI (recommended by Beanstalk and AWS) ===

The 'de facto' solution of one war running on multiple beanstalk environments is to use the system property "JDBC_CONNECTION_STRING".
You would configure it with your database url and use in your datasources.groovy like this

production {

        dataSource {
           
            username = "rds_user"
            password ="rds_password"

            url = System.getProperty("JDBC_CONNECTION_STRING")
        }
}

In beanstalk configuration, it allows you to configure more 5 extra parameters (PARAM1, PARAM2, PARAM3, PARAM4, PARAM5).
Unfortunately, you can't change the param names, but in my case, I'm using PARAM1 for username and PARAM2 for password, so, my dataSource closure is like this:

production {

        dataSource {
           
            username = System.getProperty("PARAM1")
            password =System.getProperty("PARAM2")

            url = System.getProperty("JDBC_CONNECTION_STRING")
        }
}

=== Second way - with JNDI ===

If you really want to use JNDI, you'll have to configure it on the Beanstalk Tomcat. The problem is that when beanstalk starts more instances due load on your environment (based on your AutoScaling configuration), the new instance will use a fresh tomcat, and will not have your configured JNDIs.

The solution, if you dont want to leave JNDI, is to use the AMI (Machine Image) that Beanstalk uses, and based on it, configure another AMI just for you, with your configuration (jndi conf). After that, you can set your environment to use your AMI instead of Beanstalk default AMI.

I really recommend you going on the first way :)
On Wed, Feb 9, 2011 at 3:38 PM, Brandon Kane <[hidden email]> wrote:
Our app is currently using a jndi lookup to get the datasource, so the pooling, etc is done by Tomcat.  What is the right way to use this property in Grails/AWS/RDS so that I can have one war file to deploy to multiple environments?


On Wed, Feb 9, 2011 at 10:06 AM, Peter Ledbrook <[hidden email]> wrote:
> Beanstalk provides you a automatically added to your tomcat system variable
> JDBC_CONNECTION_STRING, that you can use in your code:
>
> jdbcUrl = System.getProperty("JDBC_CONNECTION_STRING")

Gah! They keep referring to it as an environment variable, so I was
using System.getenv(). No wonder that wasn't working.

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






123