none
Passthru files RRS feed

  • Question

  • In the IAG is there to configure the trunk such that certain files, such as jar or zip archives, merely pass through the IAG to the client without doing any inspection?

     

    thanks

     

    Friday, October 29, 2010 5:28 PM

Answers

  • Thanks Ran for all the help.  Through various configuration it looks like I have been able to eliminate the IAG as the source of the performance bottleneck but I do appreciate all of the advise.  I now know more about the IAG that I ever intended to.
    Friday, November 5, 2010 1:47 PM

All replies

  • Hi Michael,

    See Specify URLs for which body parsing is not enabled per application server in the Skipping body parsing for HAT configuration in IAG TechNet article.

    Regards,

     


    -Ran
    • Proposed as answer by MrShannon Saturday, October 30, 2010 2:30 PM
    Saturday, October 30, 2010 8:36 AM
  • Hi Ran,

     

    Thanks for the suggestion.  Unfortunately that is exactly what we had done but to no avail.  We must have something wrong in the url or regular expression we're using.  Is there a trace or log setting that we can turn on to see exactly what the IAG is receiving from the back end application server?

     

    thanks

    mgms..

    Tuesday, November 2, 2010 1:31 PM
  • Hi Ran,

     

    Thanks for the suggestion.  Unfortunately that is exactly what we had done but to no avail.  We must have something wrong in the url or regular expression we're using.  Is there a trace or log setting that we can turn on to see exactly what the IAG is receiving from the back end application server?

     

    thanks

    mgms..


    How have you defined the entries?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, November 2, 2010 3:30 PM
    Moderator
  • We've tried two ways:

    First:

    /oracle/product/ora1013core/j2ee/applicationName /applications/applicationName -ear-2.0/applicationName -war-2.0/.*\.jar

    where applicationName is the name of our application and then:

    .*\.jar

     

    Also, is there any other setting that would impact whether or not the skip body parsing setting for responses take effect?

    thanks

    mgms...

    Tuesday, November 2, 2010 3:39 PM
  • I have used the following approach for UAG with SharePoint body parsing problems, but it should be very similar as a generic example and still applicable to IAG:

    1.       In the UAG console, open the Advanced Trunk Configuration.

    2.       Switch to the Portal Tab

    3.       Click on “Do not parse the response bodies to these requests:” (it’s the 2<sup>nd</sup> item on the left)

    4.       Click Add on the top.

    5.       Type in the internal name of the SharePoint server (same one used in the SPS application’s properties). If the server is an FQDN, then type a slash before the dots. For example: sps\.mitre\.org

    6.       Click Add at the bottom (for adding a URL)

    7.       Type: “.*listfeed.*” (without the quotes – dot, star, listfeed, dot, star)

    8.       Activate your configuration and test.

    Props to Ben Ari for the above help in the past ;)

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, November 2, 2010 3:59 PM
    Moderator
  • Hi Jason,

    Essentially that is what we had done, though we just changed the regex to something more like what yo had listed on item 7.  But no impact, we still are having major performance problems when trying run our applets through the IAG.  When the IAG is not part of the equation the download of the jars for the applets takes 2-20 seconds depending on whether we have ssl turned or not.  When going through the IAG it takes 60-90 seconds.  We really need to figure this out and any other suggestions are greatly appreciated. 

     

    thanks

    mgms...

    Tuesday, November 2, 2010 4:49 PM
  • Hi Jason,

    Essentially that is what we had done, though we just changed the regex to something more like what yo had listed on item 7.  But no impact, we still are having major performance problems when trying run our applets through the IAG.  When the IAG is not part of the equation the download of the jars for the applets takes 2-20 seconds depending on whether we have ssl turned or not.  When going through the IAG it takes 60-90 seconds.  We really need to figure this out and any other suggestions are greatly appreciated. 

     

    thanks

    mgms...


    Ok, sorry, not sure as this has normally worked for me (not like your specific scenario though)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, November 2, 2010 7:53 PM
    Moderator
  • Hi Michael,

    What version of IAG are you using?

    I might be bringing up pre-historic stuff, circa Jurassic era, since the days T-Rexes, Dilophosauruses and Velociraptors were still roaming the earth, but there was a time when IAG was unnecessarily accumulating before sending the files that would pass through it on their way to the browser, even when those files did not need to be parsed at all (which should be the case with files with the extension .zip and .jar, like in your case). Can you take a look at the information in the Fix for download parsing behavior section at the top of the Description of Update 5 for IAG 2007 SP 1 article, to see if it gives you any pointers?

    Regards,


    -Ran
    Wednesday, November 3, 2010 10:34 AM
  • Hi Ran,

    You might be on to something there.  We're on version 3.6.1 service pack 1.46 update 4.55.  Reading the information in the article states that accumulation happens by default.  If this is our situation do you know of a way to control the default behavior?

     

    thanks

    mike

    Wednesday, November 3, 2010 1:57 PM
  • Hi Mike,

    So, it looks like you are on e-Gap 3.6 SP1 Update 4. If that's the case, according to http://support.microsoft.com/kb/961150 you should be OK, since Update 4 fixed the accumulation issue for e-Gap 3.6 SP1, just like the Update 5 I mentioned above fixed it for IAG 2007 SP1. In that case, some good ol' fashion troubleshooting might be needed. Do you know how to turn on the e-Gap Filter log?


    -Ran
    Wednesday, November 3, 2010 9:04 PM
  • Hi Ran,

    Not to show my IAG ignorance - but ah no I don't know how to turn on the filter log or where it resides.  

    thanks

    Wednesday, November 3, 2010 9:13 PM
  • Mike,

    You turn the Filter log on by accessing the registry, at HKLM\SOFTWARE\WhaleCom\e-Gap\von\UrlFilter. There’s a DWORD value there named LogFlag. Change its value from 0 to 4. No reboot or service restart is needed.

    Within up to 30 seconds a file will be created in the …\von\conf\websites\<trunk name>\Logs folder. Once you see the file created, go ahead and repro the issue. Then go back to the registry and change LogFlag back to 0 to turn logging off.

    Note that the log file is very verbose, so it will contain a lot of information for even just one single HTTP request and response round-trip through e-Gap. So try log on to the trunk and browse to wherever you need to first without the log turned on, then turn on logging only right before you click on the specific link that downloads the file you’re interested in, and then turn logging off as soon as that file is downloaded.

    Do not forget the log turned on, or else, depending on the amount of traffic this e-Gap handles, you’ll run out of disk space sooner or later.

    Now the hard part: reading the log. I can’t give you too many pointers on this. You’ll just have to work your way through the many lines of information, and look for something along the lines of “response from RWS to filter” (RWS stands for “real web server”). This is where e-Gap receives the HTTP response headers from the backend app. From there on, it should start receiving the HTTP response data, probably in chunks. Try to see if you can understand from the log if e-Gap accumulates these chunks, and sends to the browser the entire response only after it had received the entire amount of data (“response from Filter to client”), or if it sends the chunks to the client browser as it receives them.

     

    Good luck!

     


    -Ran
    Wednesday, November 3, 2010 10:06 PM
  • Thanks Ran for all the help.  Through various configuration it looks like I have been able to eliminate the IAG as the source of the performance bottleneck but I do appreciate all of the advise.  I now know more about the IAG that I ever intended to.
    Friday, November 5, 2010 1:47 PM
  • I now know more about the IAG that I ever intended to.


    :)

    You're welcome.  I hope it will come in handy at some point.


    -Ran
    Friday, November 5, 2010 2:11 PM