Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Critical
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 1.0.1, KFS Release 3.0
    • Component/s: Development
    • Labels:
      None
    • Rice Module:
      KSB
    • Application Requirement:
      KFS

      Description

      see linked issue

        Attachments

          Issue Links

            Activity

            Hide
            abyrne Ailish Byrne added a comment -

            more standalone stuff, so i think this would be you. this came from our conversations on the server issues...

            From: Byrne, Ailish M
            Sent: Thursday, October 08, 2009 4:42 PM
            To: Westfall, Eric Curtis; Jonathan Keller
            Cc: jjhanson@iastate.edu; gpt@umd.edu; Farooq Sadiq
            Subject: RE: kfs-cnv is up

            ok i dunno what the http.url system parm is, but if you tell me i'll log a bug. also... the parm lookup on krkul-cnv is hosed because of kfs... and i think the same would go here as you were saying for doc search - you don't want the parm lookup to be broken for everyone, because one app is down or whatever - and probably the same for kim stuff too?

            From: Westfall, Eric Curtis
            Sent: Thursday, October 08, 2009 4:33 PM
            To: Byrne, Ailish M; Jonathan Keller
            Cc: jjhanson@iastate.edu; gpt@umd.edu; Farooq Sadiq
            Subject: Re: kfs-cnv is up

            Yes, and my attempts to keep up with what's happening in real time are utterly failing I think I'll stop now and try again when I get back to bloomington.

            Let me know if you figure anything else out in the meantime.

            Thanks,
            Eric

            On 10/8/09 3:29 PM, "Byrne, Ailish M" <abyrne@indiana.edu> wrote:
            i've been trying to get kfs-cnv running on both wsa125 and 137 all week, but failing. tues and weds we were running on 137 and thurs on 125. now, we're not running either place, cuz i decided to flip standalone rice off so the testers could do stuff. i deleted the wars from both servers a couple of hours ago - this is fun

            From: Westfall, Eric Curtis
            Sent: Thursday, October 08, 2009 4:27 PM
            To: Jonathan Keller; Byrne, Ailish M
            Cc: jjhanson@iastate.edu; gpt@umd.edu; Farooq Sadiq
            Subject: Re: kfs-cnv is up

            Well, one thing of interest, I think the remoting calls should be going against the internal ip addresses instead of test.kuali.org because of the http.url system parameter that's being used. I just checked the service registry and that's not the case.

            https://test.kuali.org/krkul-cnv/ksb/ServiceRegistry.do

            However, it actually shouldn't matter because it looks like only one instance of kfs-cnv is running anyway (is that supposed to be the case? I thought you guys were running it on wsa125 and wsa137).

            Thanks,
            Eric

            Show
            abyrne Ailish Byrne added a comment - more standalone stuff, so i think this would be you. this came from our conversations on the server issues... From: Byrne, Ailish M Sent: Thursday, October 08, 2009 4:42 PM To: Westfall, Eric Curtis; Jonathan Keller Cc: jjhanson@iastate.edu; gpt@umd.edu; Farooq Sadiq Subject: RE: kfs-cnv is up ok i dunno what the http.url system parm is, but if you tell me i'll log a bug. also... the parm lookup on krkul-cnv is hosed because of kfs... and i think the same would go here as you were saying for doc search - you don't want the parm lookup to be broken for everyone, because one app is down or whatever - and probably the same for kim stuff too? From: Westfall, Eric Curtis Sent: Thursday, October 08, 2009 4:33 PM To: Byrne, Ailish M; Jonathan Keller Cc: jjhanson@iastate.edu; gpt@umd.edu; Farooq Sadiq Subject: Re: kfs-cnv is up Yes, and my attempts to keep up with what's happening in real time are utterly failing I think I'll stop now and try again when I get back to bloomington. Let me know if you figure anything else out in the meantime. Thanks, Eric On 10/8/09 3:29 PM, "Byrne, Ailish M" <abyrne@indiana.edu> wrote: i've been trying to get kfs-cnv running on both wsa125 and 137 all week, but failing. tues and weds we were running on 137 and thurs on 125. now, we're not running either place, cuz i decided to flip standalone rice off so the testers could do stuff. i deleted the wars from both servers a couple of hours ago - this is fun From: Westfall, Eric Curtis Sent: Thursday, October 08, 2009 4:27 PM To: Jonathan Keller; Byrne, Ailish M Cc: jjhanson@iastate.edu; gpt@umd.edu; Farooq Sadiq Subject: Re: kfs-cnv is up Well, one thing of interest, I think the remoting calls should be going against the internal ip addresses instead of test.kuali.org because of the http.url system parameter that's being used. I just checked the service registry and that's not the case. https://test.kuali.org/krkul-cnv/ksb/ServiceRegistry.do However, it actually shouldn't matter because it looks like only one instance of kfs-cnv is running anyway (is that supposed to be the case? I thought you guys were running it on wsa125 and wsa137). Thanks, Eric
            Hide
            ewestfal Eric Westfall added a comment -

            Ailish, this is actually more of an issue with the KFS configuration of it's KSB instance I think. There aren't any Kuali Rice changes required here. I checked on wsa137 and I see the following system parameter being passed to Tomcat startup:

            -Dhttp.url=129.79.216.129:8802

            So this is good and how it's supposed to be. However, there is a configuration parameter for the KSB called serviceServletUrl. You will want to set this value to:

            serviceServletUrl=http://$

            {http.url}

            /remoting

            I checked and it looks like you are currently setting the value in your spring-rice-configurer.xml to:

            serviceServletUrl="$

            {application.url}

            /remoting"

            That value is ok for development or even a deployment of KFS in a non-clustered enviroment, but in a clustered environment it needs to be unique for each machine which is the purpose of that http.url system parameter (which is how we've chosen to implement it here at IU which I why i suggested it for our kuali test environments as well).

            Does that make sense?

            Show
            ewestfal Eric Westfall added a comment - Ailish, this is actually more of an issue with the KFS configuration of it's KSB instance I think. There aren't any Kuali Rice changes required here. I checked on wsa137 and I see the following system parameter being passed to Tomcat startup: -Dhttp.url=129.79.216.129:8802 So this is good and how it's supposed to be. However, there is a configuration parameter for the KSB called serviceServletUrl. You will want to set this value to: serviceServletUrl= http://$ {http.url} /remoting I checked and it looks like you are currently setting the value in your spring-rice-configurer.xml to: serviceServletUrl="$ {application.url} /remoting" That value is ok for development or even a deployment of KFS in a non-clustered enviroment, but in a clustered environment it needs to be unique for each machine which is the purpose of that http.url system parameter (which is how we've chosen to implement it here at IU which I why i suggested it for our kuali test environments as well). Does that make sense?
            Hide
            abyrne Ailish Byrne added a comment -

            yes, fabulous. i'll get this fixed on our side - thanks!

            Show
            abyrne Ailish Byrne added a comment - yes, fabulous. i'll get this fixed on our side - thanks!
            Hide
            abyrne Ailish Byrne added a comment -

            not a rice issue - a kfs issue

            Show
            abyrne Ailish Byrne added a comment - not a rice issue - a kfs issue

              People

              • Assignee:
                jjhanso Jeremy Hanson
                Reporter:
                jkneal Jerry Neal (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: