Thanks kong!

jgreening you will want to keep an eye on the plugin for version 1.0.9 to be released, should be soon.

I have include an extra parameter in opensearch plugin

for example :

original link = http://localhost:8090/plugins/servlet/opensearch?query=confluence&format=rss_1.0&os_authType=basic
Added parameter = http://localhost:8090/plugins/servlet/opensearch?query=confluence$$content=500$$&format=rss_1.0&os_authType=basic

the param meaning as below
$$content=500$$ mean to display first 500 characters only
$$content=-1$$ mean not to display the description at all
$$content=0$$ by default, if you didnt specify at the link and it will return the full page content.

It will be fixed for this issue and https://bitbucket.org/atlassian/opensearch-plugin/issue/16/option-to-customize-search-result-content
And will reflected in the latest version of opensearch plugin , which is v1.0.9

Thank you very much, John! I appreciate it.

Have a great day!

Jessie

Hi jgreening, I spoke with bgriebeler who let me know you enquired about this ticket and the one tracked here on BitBucket.

I've spoken with the team who look after the plugin and this work is not currently scheduled but they are aware of both tickets. If you keep a watch on both you'll be updated on any movement as soon as it happens.

Hi Bill,

Since I'm guessing this might need logs or other confidential information of yours to help diagnose this is best managed in the support ticket which only the reporter (Jessie) and Atlassian can see, so updates will happen on it.

I've added a quick note on there to see if we can speed things up for you.

John

Please provide Jessie Greening & I with an update status on this.
Thank you,
Bill Schrader

Hi Bill,

Sorry for the late reply.

I didn't realise it was failing with as little as 10 records, I'd taken away from our discussion that it was only when you searched for something with a very large result set (I think the example given was tape).

I've seen that Jessie raised a support ticket so I'll jump on there and leave a note as it seems like truncation or none 10 pages doesn't seem like an amount that should cause a problem so there may be an underlying issue that is worth investigating.

Regards,
John

2 Issues with truncating results
---------------------------------
1. The most important issue with truncation is that we will not be able to create a snippet that is relevant to the search terms. This should already occur in the returned results & truncated properly from OpenSearch/Confluence.
2. While technically feasible to use start & count to reduce records, we are currently only grabbing 10 records & this exceeds memory limitation. Returning results 1 at a time & truncating is both cumbersome & more importantly a huge performance barrier.

barconati and I had a chat with 3M this morning which including discussing this ticket and the related CONF-23139.

Some additional background:

• Need the search results in XML so what is returned can be manipulated and the required information shown
• Although (as per second part of CONF-23139) it would be ideal to be able to just receive a snippet of the page in the results, the driving problem is:
• When a person searches for something very common (eg: tape)! the server fails due to exceeding available memory

Initial Followup for 3M:
One of our engineers referred us to the documentation here: https://studio.atlassian.com/wiki/display/OPNSRCH/Home which details the available paramaters including the "start" and "count" paramaters that you could use to paginate the results.

If you haven't already tried this, it should solve the problem of the server trying to retrieve too many results at once. You would then be able to trim the descriptions as part of your manipulation of the xml on the other system.