Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

Yonik Seeley-2-2
FYI, rather than spamming the list with backports, I'm going to start
batching my backports to the 3x branch.

All the svn:mergeinfo updates for even the smallest merge is a real
nightmare.  Merges to the 3x branch are practically unreadable since
the real update is lost in the noise.

-Yonik
http://www.lucidimagination.com


On Sun, Oct 17, 2010 at 12:28 PM,  <[hidden email]> wrote:

> Author: yonik
> Date: Sun Oct 17 16:28:37 2010
> New Revision: 1023520
>
> URL: http://svn.apache.org/viewvc?rev=1023520&view=rev
> Log:
> close the request we created
>
> Modified:
>    lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java
>
> Modified: lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java
> URL: http://svn.apache.org/viewvc/lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java?rev=1023520&r1=1023519&r2=1023520&view=diff
> ==============================================================================
> --- lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java (original)
> +++ lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java Sun Oct 17 16:28:37 2010
> @@ -23,6 +23,7 @@ import org.apache.solr.common.params.Sol
>  import org.apache.solr.common.util.NamedList;
>  import org.apache.solr.common.util.XML;
>  import org.apache.solr.core.SolrCore;
> +import org.apache.solr.request.LocalSolrQueryRequest;
>  import org.apache.solr.request.SolrQueryRequest;
>  import org.apache.solr.request.SolrQueryRequestBase;
>  import org.apache.solr.response.SolrQueryResponse;
> @@ -117,15 +118,13 @@ public class XmlUpdateRequestHandler ext
>    */
>   @Deprecated
>   public void doLegacyUpdate(Reader input, Writer output) {
> -    try {
> -      SolrCore core = SolrCore.getSolrCore();
> +    SolrCore core = SolrCore.getSolrCore();
> +    SolrQueryRequest req = new LocalSolrQueryRequest(core, new HashMap<String,String[]>());
>
> +    try {
>       // Old style requests do not choose a custom handler
>       UpdateRequestProcessorChain processorFactory = core.getUpdateProcessingChain(null);
>
> -      SolrParams params = new MapSolrParams(new HashMap<String, String>());
> -      SolrQueryRequestBase req = new SolrQueryRequestBase(core, params) {
> -      };
>       SolrQueryResponse rsp = new SolrQueryResponse(); // ignored
>       XMLStreamReader parser = inputFactory.createXMLStreamReader(input);
>       UpdateRequestProcessor processor = processorFactory.createProcessor(req, rsp);
> @@ -142,6 +141,9 @@ public class XmlUpdateRequestHandler ext
>         log.error("Error writing to output stream: " + ee);
>       }
>     }
> +    finally {
> +      req.close();
> +    }
>   }
>   //////////////////////// SolrInfoMBeans methods //////////////////////
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

Robert Muir
On Sun, Oct 17, 2010 at 12:33 PM, Yonik Seeley
<[hidden email]> wrote:
> FYI, rather than spamming the list with backports, I'm going to start
> batching my backports to the 3x branch.
>
> All the svn:mergeinfo updates for even the smallest merge is a real
> nightmare.  Merges to the 3x branch are practically unreadable since
> the real update is lost in the noise.

And its only going to get worse, I mean its pretty likely we might do
more refactoring between Lucene/Solr, moving files around and
requiring more mergeprops.

If we don't do something to filter the diffs, I can easily see a
single line merge being 20 emails soon.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

Mark Miller-3


On Sun, Oct 17, 2010 at 12:58 PM, Robert Muir <[hidden email]> wrote:
On Sun, Oct 17, 2010 at 12:33 PM, Yonik Seeley
<[hidden email]> wrote:
> FYI, rather than spamming the list with backports, I'm going to start
> batching my backports to the 3x branch.
>
> All the svn:mergeinfo updates for even the smallest merge is a real
> nightmare.  Merges to the 3x branch are practically unreadable since
> the real update is lost in the noise.

And its only going to get worse, I mean its pretty likely we might do
more refactoring between Lucene/Solr, moving files around and
requiring more mergeprops.

If we don't do something to filter the diffs, I can easily see a
single line merge being 20 emails soon.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



Is it really worth doing the merges when we are not going to reintegrate?
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

Robert Muir
On Mon, Oct 18, 2010 at 11:46 PM, Mark Miller <[hidden email]> wrote:

>
> Is it really worth doing the merges when we are not going to reintegrate?
>

yes, it tracks what has and has not been backported. as mentioned
before, most patches wouldnt apply again anyway.

you bring up the same thing as grant, but i dont understand what the
"easier" option is: redoing the work again?!

again, if you aren't going to use the version control methods, thats
your choice. but set the mergeprops properly so that the end result is
the same, and those of us using svn can track what has/hasn't been
backported.

and if you arent using merge/marking merged, i don't know how you keep
up with what has/hasn't been backported...!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]