createSubtaskLink yields 'Buffer quota exceeded' message

[John Pool]

I recently installed the JIRA Extended Webservice, in order to be able
to create subtasks. In doing so, I try to use *createSubtaskLink*.
Unfortunately, this does not work, since calling this method results
in the exception:
_The size necessary to buffer the XML content exceeded the buffer
quota_.

I tried to solve this by appending zeroes to almost every quantity in
the app.config file, but without any luck.

Anyone any suggestions?

Regards – John Pool

[Ath]

John,

We'll need a few facts before we can make any kind of assessment:
- What programming environment are you running on your client-side, Java, .NET, Perl, Phyton?
- What version of Jira are you running it against? Anything after 4.2 _could_ possibly go wrong, AFAIK.
- XML buffer quota issues smell like .NET and packing up things wrongly. You'd better increase buffersize by factors of 1024, not 10.

HTH,
Ath

[Ath]

John,

In open response to your e-mail:

For .NET (either 3.5 or 4.0) some of the SOAP binding parameters (in the <app>.exe.config file) are set to 64 kB (maxBufferSize="65536", maxReceivedMessageSize="65536"). I upped those numbers to 2 MB (maxBufferSize="214748364", maxReceivedMessageSize="214748364"), after which it started to work.
Despite the text on this page (http://msdn.microsoft.com/en-us/library/system.servicemodel.basichttpbinding.maxbuffersize.aspx) where is ttated that even if the buffer is too small, extra memory is allocated, with Jira it tends to fail, maybe because of other configuration settings, but I have never investigated that further.
Other reasons for such calls to fail are that the parameters supplied do not match up with what is expected (the supplied id's do exist?). Exception handling between Jira (Java) and a .NET Client is not quite so 'optimal', usually resulting in the XML-size error you mentioned :-|

This is a small part of my C# testing code to create an issueLink:

        static void displayProject(RemoteProject proj, SoapExtensionClient jir, String token)
        {
            string mainIssue = "ATH-1";
            string subIssue = "ATH-2";
            long mainIssueId = long.Parse(jir.getIssue(token, mainIssue).id);
            long subIssueId = long.Parse(jir.getIssue(token, subIssue).id);
            long issueTypeId = -1;
 
            try
            {
                long.TryParse(Externals.jiraParseSubtaskIssuetype("Software task", jir, token), out issueTypeId);
                if (issueTypeId != -1)
                {
                    jir.createSubtaskLink(token, mainIssueId, subIssueId, issueTypeId);
 
                    Console.WriteLine("createSubtaskLink done. issueTypeId: " + issueTypeId);
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine("createSubtaskLink exception: " + ex.Message);
            }
        }

Where the method Externals.jiraParseSubtaskIssuetype() fetches the ID for the subtask with a specific description/name text.

HTH
Ath

[Ath]

John,

Again you replied by e-mail, can you please respond in this thread, for others to benefit from the information?

A few more checks:
- Are you actually connecting to the Extended Webservice, and not to the standard SOAP connector address of Jira?
  The url should end in /rpc/soap/sharedspace-s1v1 and not /rpc/soap/jirasoapservice-v2
  You need to make a new Service Reference in Visual Studio (I'm working with VS2010, may be called WebReference in VS2008) to use the changed connection, updating from an existing standard connection to the extended connector I never got working properly, deleting and re-creating always worked.
  I used a basicHttpBinding (non-https) for testing, and added the proper attributes for a https connection only for production, much easier when testing, the url for my local testserver (on linux in VMWare) was: http://192.168.153.129:8080/rpc/soap/sharedspace-s1v1
- Changing the several .svc files you found won't work, the setting from the app.exe.config file overrides that, and that will optionally be overridden when set from your code (but that should not be done, setting from .exe.config is the preferred method).
- Do other (standard) calls work as expected? You could try addVersion(), that is quite similar, but supplied by the standard SOAP connector.

If all else fails:
 Upgrade your server to Jira 5 (Jira 4.x is pretty crap with REST, and not quite compatible with 5), and start using the REST connector. (Start the upgrade with your development environment!) REST the Atlassian preferred/endorsed way of connecting to Jira. It supports all functionality of the standard SOAP service (AFAICS), and adds most of the features added by the Extended SOAP service. Some features have to be used somewhat differently though.
I'm currently working on migrating our existing SOAP connector to REST, so that when we switch over (which should happen asap, after I migrate the connector :) ), having a working alternative for the SOAP connector, as the extended soap connector is incompatible with Jira 5! (see my corresponding thread in this group)
I'm using RestSharp (from restsharp.org) and Json.NET (from json.codeplex.com) (I have no connection with these projects other than being a user) for super-easy connecting and object-mapping to Jira.

Oh, and keep up the spirit! Programming is supposed to be fun :)

HTH
Ath