Memory & performance issues


  • I am trying to use the TFS Java API within a web application to allow a user to create work items in arbitrary TFS projects. In general this works OK, but I'm seeing some major memory and performance issues.

    Due to the nature of our web-based application, a new TFS connection needs to be opened for each web request (sometimes even multiple connections per request). For each connection a lot of (mostly unneeded) metadata is downloaded by the TFS API on calls to getWorkItemClient(), especially on TFS instances with many projects.

    The first issue that we noticed was a memory leak (190MB per request) because stale HSQLDB references were not cleaned up. We solved this by changing the HSQLDB connection URL:
    System.setProperty("jdbc.connection.url", "jdbc:hsqldb:BUGTRACKER-TFS;shutdown=true;hsqldb.default_table_type=cached");

    Here, the shutdown=true property makes sure that stale HSQLDB references are shut down. We were hoping that cached table type would allow the TFS API to re-use TFS data between requests, limiting the amount of data that needs to be downloaded each time from TFS. Unfortunately, apparently this doesn't help much.

    This leaves us with the performance issue, mostly caused by the large amount of data being exchanged between TFS and the web application. Does anyone have any ideas for solving this issue?

     BTW The basic flow for a single web request is as follows:

    1. tfs = new TFSConfigurationServer(url, ...)
    2. tpcRes = find resource with a given displayName in results from tfs.getCatalogService().queryResourcesByType(CatalogResourceTypes.PROJECT_COLLECTION)
    3. tpc = tfs.getTeamProjectCollection(new GUID(tpcRes.getProperties().get("InstanceId"));
    4. prj = tpc.getWorkItemClient().getProjects().get(projectName);
    5. wi = prj.getWorkItemClient().newWorkItem(type);
    6. wi.getFields().getField(...).setValue(...);
    8. tfs.close();

    I use similar API's to fill a form which contains a list of all Team Project Collections, the Projects within each Team Project Collection, the available work item types for each project, etc.

    Monday, July 09, 2012 10:41 AM

All replies

  • Sorry for the delay in responding - would you be able to drop me a line ( so that I can better understand what you are trying to do and then we can figure out together how best to build it? 

    Currently, most testing of the SDK has been in scenarios like we use it for ourselves (such as a single session from a client machine) rather than in a web application.  However there are some things we can configure with the Work Item Tracking meta-data handling in particular but also the native code loading that should improve matters - but it would be good to understand the scenarios exactly first.

    For folks following along on this thread, I'll post back once we have come to some conclusions.

    Thanks again,


    Monday, July 23, 2012 1:02 PM