View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0011180mantisbtapi soappublic2009-11-15 15:212014-02-05 07:55
Reporterrombert Assigned Torombert  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product Version1.2.0rc2 
Summary0011180: [this bugtracker] mc_project_get_users fails to return all reporters
Description

If I try to retrieve the developers, all is fine. If I try to retrieve the reporters, the proxy server I use reports a zero sized reply. The request is

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:man="http://futureware.biz/mantisconnect">

<soapenv:Header/>

<soapenv:Body>

<man:mc_project_get_users soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<username xsi:type="xsd:string">rombert</username>

<password xsi:type="xsd:string">xxx</password>

<project_id xsi:type="xsd:integer">1</project_id>

<access xsi:type="xsd:integer">25</access>

</man:mc_project_get_users>

</soapenv:Body>

</soapenv:Envelope>

This call took place at Sun, 15 Nov 2009 18:25:04 GMT.

I'd appreciate some ( private if needed ) logging information, so that I can see why it fails.

TagsNo tags attached.

Activities

vboctor

vboctor

2009-11-16 02:12

manager   ~0023728

I would expect that the request caused an out of memory error. This bug tracker has thousands of reporters.
rombert

rombert

2009-11-18 15:16

reporter   ~0023753

Sounds correct, and there are workarounds on the client side. On the other side, I'm concerned about trying to retrieve the user information only to fail every time . The Mylyn connector for Eclipse does this quite rarely - perhaps once per day, but other clients may not be so forgiving.

What would be a server-side solution for this?
vboctor

vboctor

2009-11-19 13:35

manager   ~0023764

I think we need to provide a paging API and put a realistic limit on the non-paging version. For example, if you don't use paging, then you get 100 max users. The limit on the non-paging API should be configurable via the webservice config file. We should potentially have this as a global limit to apply to users, projects, etc. However, we should only apply it to an API, once we have a paging version of it.
rombert

rombert

2009-12-28 04:27

reporter   ~0023997

Not for this version of the API. Will revisit in the 1.3.x stream.
vboctor

vboctor

2009-12-28 11:56

manager   ~0024002

We typically don't suspend issues. If this issue is for 1.3, then we should set the target version as appropriate or just leave it blank.

The trunk is now the development branch and hence feel free to do the fix there and not port to 1.2.x branch. However, I would like to discuss the new API here before going ahead with the implementation.

Thanks.
rombert

rombert

2009-12-28 14:03

reporter   ~0024003

Re-opening.
rombert

rombert

2010-12-23 19:00

reporter   ~0027688

Some recent tests showed that the memory is used by the SOAP marshalling, and not the actual user retrieval, so there isn't much to be done here, except changing the API.
dregad

dregad

2013-10-28 06:33

developer   ~0038368

@rombert, is this still an issue ?
rombert

rombert

2013-10-29 18:07

reporter   ~0038385

Colour me impressed, this actually works :-)

I suspect that we're now running with the PHP Soap extension instead of nusoap, and this brings about the improvement.