Re: Team please help

[Greg Solovyev]

Sujeet, what do you mean by migrating? E.g., are you moving your data from
Cloudera CDH to Azure HDI? Are migrating your application code written on
top of Cloudera CDH to run on top of Azure HDI? As far as I know, Azure HDI
does not include Solr, so if your application on top of Cloudera CDH is
using Solr, it won't run on HDI.
Greg

On Sat, Apr 28, 2018 at 5:45 PM Sujeet Singh 
wrote:

> Adding Dev
>
>
>
> *From:* Sujeet Singh
> *Sent:* Sunday, April 29, 2018 12:14 AM
> *To:* 'solr-u...@lucene.apache.org'
> *Subject:* Team please help
>
>
>
> Team I am facing an issue right now. I am working ahead to migrate
> cloudera to HDI Azure. Now cloudera has Solr implementation and using the
> below jar
>
> search-mr-1.0.0-cdh5.7.0-job.jar
> org.apache.solr.hadoop.MapReduceIndexerTool
>
>
>
> While looking into all option I found “solr-map-reduce-4.9.0.jar” and
> tried using it with class “org.apache.solr.hadoop.MapReduceIndexerTool”. I
> tried adding lib details in solrconfig.xml but did not worked . Getting
> error
>
> “Caused by: java.lang.ClassNotFoundException:
> org.apache.solr.morphlines.solr.DocumentLoader”
>
>
>
> Please let me know the right way to use MapReduceIndexerTool class.
>
>
>
> Regards,
> --
>
> *Sujeet Singh* | Sr. Software Analyst | cloudmoyo | *E.*
> sujeet.si...@cloudmoyo.com | *M.* +91 9860586055 <+91%2098605%2086055>
>
> [image: CloudMoyo Logo]
> 
> [image:
> https://icertisportalstorage.blob.core.windows.net/siteasset/icon-linkedin.png]
> [image:
> https://icertisportalstorage.blob.core.windows.net/siteasset/icon-fb.png]
> [image:
> https://icertisportalstorage.blob.core.windows.net/siteasset/icon-twitter.png]
> 
> www.cloudmoyo.com
>
>
>

[jira] [Updated] (SOLR-7170) exceptions thrown by SolrJ do not provide sufficient information to gracefully handle errors

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7170:

Summary: exceptions thrown by SolrJ do not provide sufficient information 
to gracefully handle errors  (was: exceptions thrown by SolrJ are do not 
provide sufficient information to gracefully handle errors)

 exceptions thrown by SolrJ do not provide sufficient information to 
 gracefully handle errors
 

 Key: SOLR-7170
 URL: https://issues.apache.org/jira/browse/SOLR-7170
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: 4.10.3
Reporter: Greg Solovyev
Priority: Minor

 Currently, exceptions thrown by SolrJ are do not provide sufficient 
 information that would enable graceful error handling. Here are some examples:
 When a Solr Collection does not exist, SolrJ throws ErrorCode.BAD_REQUEST 
 with message Could not find collection:  or Could not find collection in 
 zk: .  The only part of the exception that hints to the type of problem is 
 the message. However, a hardcoded text message is not a reliable point of 
 data to be used in exception handling. It would be much cleaner if SolrJ 
 expanded its library of Error Codes and used them to specify what type of 
 error has occurred. E.g. :
 ErrorCode.CANNOT_FIND_COLLECTION (for the above example)
 ErrorCode.NO_LIVE_NODES (instead of just SolrServerException(No live 
 SolrServers available to handle this request))
 ErrorCode.BAD_RESPONSE (instead of just SolrServerException(Expected JSON 
 object in response from ...)
 etc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-7713) Expose a configuration option to register softCommit callbacks via solrconfig.xml

[Greg Solovyev (JIRA)]

Greg Solovyev created SOLR-7713:
---

 Summary: Expose a configuration option to register softCommit 
callbacks via solrconfig.xml
 Key: SOLR-7713
 URL: https://issues.apache.org/jira/browse/SOLR-7713
 Project: Solr
  Issue Type: Improvement
Reporter: Greg Solovyev
Priority: Trivial


Currently event listeners can be registered only for hard commits using  
listener event=postCommit  call in solrconfig.xml. A listener registered 
this way is not called on soft commits. There is an API to listen to soft 
commits, so a listener can be registered via an API call, but for some reason 
there is no way to add a postSoftCommit listener in solronfig.xml.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568459#comment-14568459
 ] 

Greg Solovyev edited comment on SOLR-7583 at 6/2/15 3:42 AM:
-

Hi [~andyetitmoves], I thought of adding an output kind of option to backup 
command, but given that backup is asynchronous, it didn't make sense to block 
the request and hold it until a backup completes. Maybe, the alternative to 
current implementation is to stream directly back to the response without an 
intermediate step of copying files and compressing them. The downside of 
streaming the zipped archive directly back is that when a download fails due to 
network interruption, it won't be possible to followup with a continue 
request that will skip to the last byte in the previously requested backup and 
continue streaming where previous request dropped off.  With current approach, 
because the backup is stored and is immutable, it is possible to add an option 
to continue the download where it was left of and to add checksum verification.


was (Author: grishick):
Hi [~andyetitmoves], I thought of adding an output kind of option to backup 
command, but given that backup is asynchronous, it didn't make sense to block 
the request and hold it until a backup completes. Maybe, the alternative to 
current implementation is to stream directly back to the response without an 
intermediate step of copying files and compressing them. The downside of 
streaming the zipped archive directly back is that when a download fails due to 
network interruption, it won't be possible to quickly skip to the last byte in 
the previously requested backup unless that backup is copied somewhere and 
zipped before streaming starts. With current approach, it is possible to add an 
option to continue the download where it was left of and to add checksum 
verification.

 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
Assignee: Mark Miller
 Attachments: SOLR-7583.patch, SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568459#comment-14568459
 ] 

Greg Solovyev commented on SOLR-7583:
-

Hi [~andyetitmoves], I thought of adding an output kind of option to backup 
command, but given that backup is asynchronous, it didn't make sense to block 
the request and hold it until a backup completes. Maybe, the alternative to 
current implementation is to stream directly back to the response without an 
intermediate step of copying files and compressing them. The downside of 
streaming the zipped archive directly back is if a download fails due to 
network interruption, it won't be possible to quickly skip to the last byte in 
the previously requested backup unless that backup is copied somewhere and 
zipped before streaming starts. With current approach, it is possible to add an 
option to continue the download where it was left of and to add checksum 
verification.

 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
Assignee: Mark Miller
 Attachments: SOLR-7583.patch, SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568459#comment-14568459
 ] 

Greg Solovyev edited comment on SOLR-7583 at 6/2/15 3:41 AM:
-

Hi [~andyetitmoves], I thought of adding an output kind of option to backup 
command, but given that backup is asynchronous, it didn't make sense to block 
the request and hold it until a backup completes. Maybe, the alternative to 
current implementation is to stream directly back to the response without an 
intermediate step of copying files and compressing them. The downside of 
streaming the zipped archive directly back is that when a download fails due to 
network interruption, it won't be possible to quickly skip to the last byte in 
the previously requested backup unless that backup is copied somewhere and 
zipped before streaming starts. With current approach, it is possible to add an 
option to continue the download where it was left of and to add checksum 
verification.


was (Author: grishick):
Hi [~andyetitmoves], I thought of adding an output kind of option to backup 
command, but given that backup is asynchronous, it didn't make sense to block 
the request and hold it until a backup completes. Maybe, the alternative to 
current implementation is to stream directly back to the response without an 
intermediate step of copying files and compressing them. The downside of 
streaming the zipped archive directly back is if a download fails due to 
network interruption, it won't be possible to quickly skip to the last byte in 
the previously requested backup unless that backup is copied somewhere and 
zipped before streaming starts. With current approach, it is possible to add an 
option to continue the download where it was left of and to add checksum 
verification.

 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
Assignee: Mark Miller
 Attachments: SOLR-7583.patch, SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

what's the process for getting a patch reviewed and merged into trunk?

[Greg Solovyev]

Hello, just wondering, what would be the process for getting a patch that I 
submitted few days ago reviewed and considered for one of the next releases? 
The patch is this one: https://issues.apache.org/jira/browse/SOLR-7583. I've 
submitted the last version about 4 days ago. 

Thanks, 
Greg 

[jira] [Commented] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559530#comment-14559530
 ] 

Greg Solovyev commented on SOLR-7583:
-


Downloading a zipped snapshot:

http://solr-host:solr-port/collection-name/replication?command=downloadbackupname=snaphostnamewt=filestream

{code:java}
InputStream stream = null;
URL url = new URL(requestURL);
stream = url.openStream();
FastInputStream is = new FastInputStream((InputStream) stream);  
String fileName = downloaded. + backupName + .zip;
String savePath = 
createTempDir().resolve(fileName).toAbsolutePath().toString();
File outFile = new File(savePath);
FileOutputStream fos = new FileOutputStream(outFile);
Long totalRead = 0L;
try {
  byte[] longbytes = new byte[8];
  is.readFully(longbytes);
  Long fileSize = readLong(longbytes);
  while(fileSize  totalRead) {
//store bytes representing packet size here
byte[] intbytes = new byte[4]; 
//read packet size
is.readFully(intbytes);
int packetSize = readInt(intbytes);
//read the packet
byte[] buf = new byte[packetSize];
is.readFully(buf, 0, packetSize);
fos.write(buf);
fos.flush();
totalRead+=(long)packetSize;
  }
} finally  {
  //close streams
  IOUtils.closeQuietly(is);
  fos.close();  
}
{code}


 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
 Attachments: SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7583:

Attachment: SOLR-7583.patch

Updated patch for trunk. Patch includes:
 - API + unit tests for downloading zipped snapshot
 - API + unit tests for restoring a core by uploading snapshot files
 - API + unit tests for restoring a core by uploading a zipped snapshot 
directory


 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
 Attachments: SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559539#comment-14559539
 ] 

Greg Solovyev commented on SOLR-7583:
-

Restoring a core by uploading a zipped snapshot:
{code:java}
ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(ReplicationHandler.COMMAND, 
ReplicationHandler.CMD_RESTORE);
restoreReq.setParam(ReplicationHandler.FILE_FORMAT, 
ReplicationHandler.FILE_FORMAT_ZIP);
restoreReq.addFile(zipFileOutput, application/octet-stream);

HttpSolrClient client = new HttpSolrClient(http://localhost:8983/; + 
restoredCoreName);  
NamedListObject result = client.request(restoreReq);
{code}

 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
 Attachments: SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559544#comment-14559544
 ] 

Greg Solovyev commented on SOLR-7583:
-

Restoring a core by uploading a snapshot folder:
{code:java}
ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles(); //folder where we have snapshot files
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}
{code}

 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
 Attachments: SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7583:

Attachment: SOLR-7583.patch

cleaned up the patch

 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
 Attachments: SOLR-7583.patch, SOLR-7583.patch, SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7583) API to download snapshot files/restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7583:

Summary: API to download snapshot files/restore via upload  (was: API to 
download a snapshot by name)

 API to download snapshot files/restore via upload
 -

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
 Attachments: SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev resolved SOLR-7567.
-
Resolution: Duplicate

patch for SOLR-7585 includes this feature

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch, SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559503#comment-14559503
 ] 

Greg Solovyev edited comment on SOLR-7567 at 5/26/15 6:04 PM:
--

patch for SOLR-7583 includes this feature


was (Author: grishick):
patch for SOLR-7585 includes this feature

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch, SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7567:

Attachment: SOLR-7567.patch

Updated patch includes restore via zip upload and directory upload. Unit tests 
are added to TestReplicationHandlerBackup for downloading a zip and to 
TestRestoreCore for restoring a core by uploading a zipped snapshot folder.

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch, SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14557469#comment-14557469
 ] 

Greg Solovyev edited comment on SOLR-7567 at 5/23/15 6:51 PM:
--

Updated patch includes restore via zip upload and directory upload. Unit tests 
are added to TestReplicationHandlerBackup for downloading a zip and to 
TestRestoreCore for restoring a core by uploading a zipped snapshot folder. 
This patch file is created from 5x branch.


was (Author: grishick):
Updated patch includes restore via zip upload and directory upload. Unit tests 
are added to TestReplicationHandlerBackup for downloading a zip and to 
TestRestoreCore for restoring a core by uploading a zipped snapshot folder.

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch, SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7567:

Attachment: (was: SOLR-7583.patch)

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Issue Comment Deleted] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7567:

Comment: was deleted

(was: This patch has this feature implemented on 5_x branch. The patch includes 
unit test for downloading a snapshot as a zip file.
REST API for downloading a zipped snapshot:

http://localhost:8983/solr/collection1/replication?command=downloadbackupname=namedBackupNamewt=filestream

The response returns a chunked filestream. First 8 bytes have the file size, 
and rest of the stream is structured the same way as if you were making 
filecontent request: 
 - 4 bytes for chunk size
 - N bytes for next chunk

there is no support for checksum yet)

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7583) API to download a snapshot by name

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7583:

Attachment: SOLR-7583.patch

This patch has this feature implemented on 5_x branch. The patch includes unit 
test for downloading a snapshot as a zip file.
REST API for downloading a zipped snapshot:

http://localhost:8983/solr/collection1/replication?command=downloadbackupname=namedBackupNamewt=filestream

The response returns a chunked filestream. First 8 bytes have the file size, 
and rest of the stream is structured the same way as if you were making 
filecontent request: 
 - 4 bytes for chunk size
 - N bytes for next chunk

there is no support for checksum yet

 API to download a snapshot by name
 --

 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev
 Attachments: SOLR-7583.patch


 What we are looking for:
 SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
 For single node Solr, this API will find a snapshot and stream it back over 
 HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
 requested name and stream the snapshot from that replica. Since there are 
 multiple files inside a snapshot, the API should probably zip the snapshot 
 folder before sending it back to the client.
 Why we need this:
 this will allow us to create and fetch fully contained archives of customer 
 data where each backup archive will contain Solr index as well as other 
 customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7567:

Attachment: SOLR-7583.patch

This patch has this feature implemented on 5_x branch. The patch includes unit 
test for downloading a snapshot as a zip file.
REST API for downloading a zipped snapshot:

http://localhost:8983/solr/collection1/replication?command=downloadbackupname=namedBackupNamewt=filestream

The response returns a chunked filestream. First 8 bytes have the file size, 
and rest of the stream is structured the same way as if you were making 
filecontent request: 
 - 4 bytes for chunk size
 - N bytes for next chunk

there is no support for checksum yet

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch, SOLR-7583.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7567:

Fix Version/s: (was: 5.2)

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk

 Attachments: SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-7583) API to download a snapshot by name

[Greg Solovyev (JIRA)]

Greg Solovyev created SOLR-7583:
---

 Summary: API to download a snapshot by name
 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev


What we are looking for:
SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
For single node Solr, this API will find a snapshot and stream it back over 
HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
requested name and stream the snapshot from that replica. Since there are 
multiple files inside a snapshot, the API should probably zip the snapshot 
folder before sending it back to the client.

Why we need this:
this will allow us to create and fetch fully contained archives of customer 
data where each backup archive will contain Solr index as well as other 
customer data (DB, metadata, files, etc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 5.2 Release branch

[Greg Solovyev]

I am fairly new to Solr development, so apologies for an obvious question. Do 
you cut 5.x releases from trunk or some other branch/tag? The reason I am 
asking is that trunk currently builds as 6.0.0 snapshots and there are a bunch 
of Lucene and Solr API differences between 5.1 and trunk. 

Thanks, 
Greg 


From: Anshum Gupta ans...@anshumgupta.net 
To: dev@lucene.apache.org 
Sent: Thursday, May 21, 2015 12:27:27 PM 
Subject: 5.2 Release branch 

Hi, 
Just a reminder, I plan to cut the release branch for 5.2 later tonight. 

-- 
Anshum Gupta 

[jira] [Commented] (SOLR-6637) Solr should have a way to restore a core

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550955#comment-14550955
 ] 

Greg Solovyev commented on SOLR-6637:
-

Posted my patch to this subtask: https://issues.apache.org/jira/browse/SOLR-7567

 Solr should have a way to restore a core
 

 Key: SOLR-6637
 URL: https://issues.apache.org/jira/browse/SOLR-6637
 Project: Solr
  Issue Type: Improvement
Reporter: Varun Thacker
Assignee: Varun Thacker
 Fix For: Trunk, 5.2

 Attachments: SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, 
 SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, 
 SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch


 We have a core backup command which backs up the index. We should have a 
 restore command too. 
 This would restore any named snapshots created by the replication handlers 
 backup command.
 While working on this patch right now I realized that during backup we only 
 backup the index. Should we backup the conf files also? Any thoughts? I could 
 separate Jira for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

Greg Solovyev created SOLR-7567:
---

 Summary: Replication handler to support restore via upload
 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev


Sometimes the snapshot is not available on a file system that can be accessed 
by Solr or SolrCloud. It would be useful to be able to send snapshot  files to 
Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5750) Backup/Restore API for SolrCloud

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14551169#comment-14551169
 ] 

Greg Solovyev commented on SOLR-5750:
-

[~varunthacker] if I am understanding the code correctly, when a collection has 
multiple shards spread over multiple nodes, data from each shard will be backed 
up only on that shard's node, metadata from ZK will be saved on whichever node 
happens to handle the backup request. Am I missing something here?

 Backup/Restore API for SolrCloud
 

 Key: SOLR-5750
 URL: https://issues.apache.org/jira/browse/SOLR-5750
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Assignee: Varun Thacker
 Fix For: Trunk, 5.2

 Attachments: SOLR-5750.patch, SOLR-5750.patch


 We should have an easy way to do backups and restores in SolrCloud. The 
 ReplicationHandler supports a backup command which can create snapshots of 
 the index but that is too little.
 The command should be able to backup:
 # Snapshots of all indexes or indexes from the leader or the shards
 # Config set
 # Cluster state
 # Cluster properties
 # Aliases
 # Overseer work queue?
 A restore should be able to completely restore the cloud i.e. no manual steps 
 required other than bringing nodes back up or setting up a new cloud cluster.
 SOLR-5340 will be a part of this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-7567:

Attachment: SOLR-7567.patch

This patch adds restore via upload feature and a unit test. To use this feature 
in SolrJ use ContentStreamUpdateRequest and omit name and location 
parameters. Example of restoring via upload using SolrJ:

  ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles();
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk, 5.2

 Attachments: SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550690#comment-14550690
 ] 

Greg Solovyev edited comment on SOLR-7567 at 5/19/15 4:17 PM:
--

This patch adds restore via upload feature and a unit test. To use this feature 
in SolrJ use ContentStreamUpdateRequest and omit name and location 
parameters. Example of restoring via upload using SolrJ:

  ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles();
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}


was (Author: grishick):
This patch adds restore via upload feature and a unit test. To use this feature 
in SolrJ use ContentStreamUpdateRequest and omit name and location 
parameters. Example of restoring via upload using SolrJ:

  ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles();
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk, 5.2

 Attachments: SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550690#comment-14550690
 ] 

Greg Solovyev edited comment on SOLR-7567 at 5/19/15 4:19 PM:
--

This patch adds restore via upload feature and a unit test. To use this feature 
in SolrJ use ContentStreamUpdateRequest and omit name and location 
parameters. Example of restoring via upload using SolrJ:
{code:java}
  ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles();
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}
{code}


was (Author: grishick):
This patch adds restore via upload feature and a unit test. To use this feature 
in SolrJ use ContentStreamUpdateRequest and omit name and location 
parameters. Example of restoring via upload using SolrJ:

  ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles();
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk, 5.2

 Attachments: SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7567) Replication handler to support restore via upload

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550690#comment-14550690
 ] 

Greg Solovyev edited comment on SOLR-7567 at 5/19/15 4:19 PM:
--

This patch adds restore via upload feature and a unit test. To use this feature 
in SolrJ use ContentStreamUpdateRequest and omit name and location 
parameters. Example of restoring via upload using SolrJ:
{code:java}
ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles();
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}
{code}


was (Author: grishick):
This patch adds restore via upload feature and a unit test. To use this feature 
in SolrJ use ContentStreamUpdateRequest and omit name and location 
parameters. Example of restoring via upload using SolrJ:
{code:java}
  ContentStreamUpdateRequest restoreReq = new 
ContentStreamUpdateRequest(/replication);
restoreReq.setParam(command, ReplicationHandler.CMD_RESTORE);
files = tmpBackupDir.listFiles();
haveFiles = false;
if (files != null) {
for (File f : files) {
if (f != null  f.getName() != null  f.exists()
 f.length()  0) {
haveFiles = true;
restoreReq.addFile(f, application/octet-stream);
}
}
}
{code}

 Replication handler to support restore via upload
 -

 Key: SOLR-7567
 URL: https://issues.apache.org/jira/browse/SOLR-7567
 Project: Solr
  Issue Type: Sub-task
Reporter: Greg Solovyev
 Fix For: Trunk, 5.2

 Attachments: SOLR-7567.patch


 Sometimes the snapshot is not available on a file system that can be accessed 
 by Solr or SolrCloud. It would be useful to be able to send snapshot  files 
 to Solr over HTTP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6637) Solr should have a way to restore a core

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14544636#comment-14544636
 ] 

Greg Solovyev commented on SOLR-6637:
-

Would it make sense to add an ability to upload index files to target Solr 
instance via HTTP using ContentStreams or is it a bad idea for any reason?

 Solr should have a way to restore a core
 

 Key: SOLR-6637
 URL: https://issues.apache.org/jira/browse/SOLR-6637
 Project: Solr
  Issue Type: Improvement
Reporter: Varun Thacker
Assignee: Varun Thacker
 Fix For: Trunk, 5.2

 Attachments: SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, 
 SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, 
 SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch


 We have a core backup command which backs up the index. We should have a 
 restore command too. 
 This would restore any named snapshots created by the replication handlers 
 backup command.
 While working on this patch right now I realized that during backup we only 
 backup the index. Should we backup the conf files also? Any thoughts? I could 
 separate Jira for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6273) Cross Data Center Replication

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14496652#comment-14496652
 ] 

Greg Solovyev commented on SOLR-6273:
-

Frankly, we would not be able to use this feature without auto-provisioning of 
collections (the feature that I added in my version of the patch). I cannot 
tell from the subtasks if this feature part of any of them. 

 Cross Data Center Replication
 -

 Key: SOLR-6273
 URL: https://issues.apache.org/jira/browse/SOLR-6273
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Erick Erickson
 Attachments: SOLR-6273.patch, SOLR-6273.patch, SOLR-6273.patch


 This is the master issue for Cross Data Center Replication (CDCR)
 described at a high level here: 
 http://heliosearch.org/solr-cross-data-center-replication/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-6273) Cross Data Center Replication

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-6273:

Attachment: SOLR-6273.patch

This patch expands the previously added patch to add the following features:
 - if source_collection is not defined - use the collection name associated 
with the Core
 - if target_collection is not defined - use the same name as source_collection
 - if target collection does not exist on the target cloud - provision it with 
the same parameters as the source collection


 Cross Data Center Replication
 -

 Key: SOLR-6273
 URL: https://issues.apache.org/jira/browse/SOLR-6273
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-6273.patch, SOLR-6273.patch


 This is the master issue for Cross Data Center Replication (CDCR)
 described at a high level here: 
 http://heliosearch.org/solr-cross-data-center-replication/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6273) Cross Data Center Replication

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14376686#comment-14376686
 ] 

Greg Solovyev commented on SOLR-6273:
-

P.S. last patch is made off of 4.10.2 tag

 Cross Data Center Replication
 -

 Key: SOLR-6273
 URL: https://issues.apache.org/jira/browse/SOLR-6273
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-6273.patch, SOLR-6273.patch


 This is the master issue for Cross Data Center Replication (CDCR)
 described at a high level here: 
 http://heliosearch.org/solr-cross-data-center-replication/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6273) Cross Data Center Replication

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14366070#comment-14366070
 ] 

Greg Solovyev commented on SOLR-6273:
-

I am working on applying this patch to test cross datacenter replication. 
Unless I am misunderstanding the code, this patch assumes that replication for 
each collection is configured in solrconfig.xml. I.e without this section in a 
collection's solrconfig.xml file the collection won't get replicated:
lst name=replica
  str name=zkHost${zkHost}/str
  str name=sourcesource_collection/str
  str name=targettarget_collection/str
/lst

This means that CDCR won't work for collections created via collections API 
using a shared configset, because when collections are created via collections 
API with a configset, all collections will have identical solrconfig.xml and so 
there is no way to overwrite source and target parameters for each collection.

 Cross Data Center Replication
 -

 Key: SOLR-6273
 URL: https://issues.apache.org/jira/browse/SOLR-6273
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-6273.patch


 This is the master issue for Cross Data Center Replication (CDCR)
 described at a high level here: 
 http://heliosearch.org/solr-cross-data-center-replication/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14353667#comment-14353667
 ] 

Greg Solovyev edited comment on SOLR-7203 at 3/9/15 9:37 PM:
-

Shawn, if you look closely at what is happening in the while loop, you will see 
that the request object is being created in it, but is not actually being sent. 
The request is being sent in HttpSolrClient::executeMethod and maxRetries is 
being used in createMethod. FWIF, there isn't anything in that while look that 
can throw NoHttpResponseException :)


was (Author: grishick):
Shawn, if you look closely at what is happening in the while loop, you will see 
that the request object is being created in it, but is not actually being sent. 
The request is being sent in HttpSolrClient::executeMethod and maxRetries is 
being used in createMethod. FWIF, there isn't anything in that while look that 
can thrown NoHttpResponseException :)

 NoHttpResponseException handling in HttpSolrClient is wrong
 ---

 Key: SOLR-7203
 URL: https://issues.apache.org/jira/browse/SOLR-7203
 Project: Solr
  Issue Type: Bug
Reporter: Alan Woodward
Assignee: Alan Woodward
 Attachments: SOLR-7203.patch, SOLR-7203.patch, SOLR-7203.patch


 We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. 
  However, this logic appears to be in the wrong place - it's in the 
 createMethod function, which doesn't actually execute any http requests at 
 all.  It ought to be in executeMethod.
 Fixing this might help sort out the persistent Jenkins failures as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14353667#comment-14353667
 ] 

Greg Solovyev commented on SOLR-7203:
-

Shawn, if you look closely at what is happening in the while loop, you will see 
that the request object is being created in it, but is not actually being sent. 
The request is being sent in HttpSolrClient::executeMethod and maxRetries is 
being used in createMethod. FWIF, there isn't anything in that while look that 
can thrown NoHttpResponseException :)

 NoHttpResponseException handling in HttpSolrClient is wrong
 ---

 Key: SOLR-7203
 URL: https://issues.apache.org/jira/browse/SOLR-7203
 Project: Solr
  Issue Type: Bug
Reporter: Alan Woodward
Assignee: Alan Woodward
 Attachments: SOLR-7203.patch, SOLR-7203.patch, SOLR-7203.patch


 We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. 
  However, this logic appears to be in the wrong place - it's in the 
 createMethod function, which doesn't actually execute any http requests at 
 all.  It ought to be in executeMethod.
 Fixing this might help sort out the persistent Jenkins failures as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14353494#comment-14353494
 ] 

Greg Solovyev commented on SOLR-7203:
-

+1

 NoHttpResponseException handling in HttpSolrClient is wrong
 ---

 Key: SOLR-7203
 URL: https://issues.apache.org/jira/browse/SOLR-7203
 Project: Solr
  Issue Type: Bug
Reporter: Alan Woodward
Assignee: Alan Woodward
 Attachments: SOLR-7203.patch, SOLR-7203.patch


 We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. 
  However, this logic appears to be in the wrong place - it's in the 
 createMethod function, which doesn't actually execute any http requests at 
 all.  It ought to be in executeMethod.
 Fixing this might help sort out the persistent Jenkins failures as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6724) HttpServer maxRetries attributes seems like not being used as expected

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14352302#comment-14352302
 ] 

Greg Solovyev commented on SOLR-6724:
-

This problem pops up in our environment fairly frequently when Solr server and 
client app run on the same machine, which is why I started looking into this. 
After reading the thread on https://issues.apache.org/jira/browse/SOLR-7203 
think that the patch I submitted is rather useless.  IMHO, it makes more sense 
to let the parent application handle all IOExceptions thrown by HttpClient when 
HttpSolrServer uses an external instance of HttpClient. Also, when 
HttpSolrServer is using internal HttpClient, it shouldn't blindly retry the 
request, but should try to clean up dead connections first and perhaps use a 
timeout before retrying.

 HttpServer maxRetries attributes seems like not being used as expected
 --

 Key: SOLR-6724
 URL: https://issues.apache.org/jira/browse/SOLR-6724
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.10.2
 Environment: OS X 10.9.5
 Java 1.7.0_60
Reporter: Márcio Furlani Carmona
Priority: Minor
 Attachments: SOLR-6724.patch


 Looks like maxRetries is being misused in the 
 org.apache.solr.client.solrj.impl.HttpSolrServer.createMethod(SolrRequest) 
 instead of being used in the executeMethod(HttpRequestBase,ResponseParser).
 In the current implementation the maxRetries is used in a loop that only 
 instantiates the HttpRequestBase but it doesn't effectively make any HTTP 
 request. Also the retries are made even in a successful instantiation  of the 
 HttpRequestBase as there's no break too.
 I notice there's also a catch for NoHttpResponseException but as no HTTP 
 request is made I guess it will never happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6724) HttpServer maxRetries attributes seems like not being used as expected

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14352397#comment-14352397
 ] 

Greg Solovyev commented on SOLR-6724:
-

This happens in the set up where Solr is running in non-cloud mode under
the same jetty instance as the client app (Zimbra) on a small VM (2GB RAM,
2 VCPU). Currently on version 4.10.2.




 HttpServer maxRetries attributes seems like not being used as expected
 --

 Key: SOLR-6724
 URL: https://issues.apache.org/jira/browse/SOLR-6724
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.10.2
 Environment: OS X 10.9.5
 Java 1.7.0_60
Reporter: Márcio Furlani Carmona
Priority: Minor
 Attachments: SOLR-6724.patch


 Looks like maxRetries is being misused in the 
 org.apache.solr.client.solrj.impl.HttpSolrServer.createMethod(SolrRequest) 
 instead of being used in the executeMethod(HttpRequestBase,ResponseParser).
 In the current implementation the maxRetries is used in a loop that only 
 instantiates the HttpRequestBase but it doesn't effectively make any HTTP 
 request. Also the retries are made even in a successful instantiation  of the 
 HttpRequestBase as there's no break too.
 I notice there's also a catch for NoHttpResponseException but as no HTTP 
 request is made I guess it will never happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7203) NoHttpResponseException handling in HttpSolrClient is wrong

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14351841#comment-14351841
 ] 

Greg Solovyev commented on SOLR-7203:
-

This is practically a duplicate of 
https://issues.apache.org/jira/browse/SOLR-6724

 NoHttpResponseException handling in HttpSolrClient is wrong
 ---

 Key: SOLR-7203
 URL: https://issues.apache.org/jira/browse/SOLR-7203
 Project: Solr
  Issue Type: Bug
Reporter: Alan Woodward
Assignee: Alan Woodward
 Attachments: SOLR-7203.patch, SOLR-7203.patch


 We've got logic in HttpSolrClient to catch NoHttpResponseException and retry. 
  However, this logic appears to be in the wrong place - it's in the 
 createMethod function, which doesn't actually execute any http requests at 
 all.  It ought to be in executeMethod.
 Fixing this might help sort out the persistent Jenkins failures as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-6724) HttpServer maxRetries attributes seems like not being used as expected

[Greg Solovyev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Solovyev updated SOLR-6724:

Attachment: SOLR-6724.patch

A straightforward patch moving retries logic from createMethod to executeMethod 
and a unit test to confirm that it works

 HttpServer maxRetries attributes seems like not being used as expected
 --

 Key: SOLR-6724
 URL: https://issues.apache.org/jira/browse/SOLR-6724
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.10.2
 Environment: OS X 10.9.5
 Java 1.7.0_60
Reporter: Márcio Furlani Carmona
Priority: Minor
 Attachments: SOLR-6724.patch


 Looks like maxRetries is being misused in the 
 org.apache.solr.client.solrj.impl.HttpSolrServer.createMethod(SolrRequest) 
 instead of being used in the executeMethod(HttpRequestBase,ResponseParser).
 In the current implementation the maxRetries is used in a loop that only 
 instantiates the HttpRequestBase but it doesn't effectively make any HTTP 
 request. Also the retries are made even in a successful instantiation  of the 
 HttpRequestBase as there's no break too.
 I notice there's also a catch for NoHttpResponseException but as no HTTP 
 request is made I guess it will never happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-6724) HttpServer maxRetries attributes seems like not being used as expected

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350661#comment-14350661
 ] 

Greg Solovyev edited comment on SOLR-6724 at 3/6/15 6:19 PM:
-

I just added a straightforward patch moving retries logic from createMethod to 
executeMethod and a unit test to confirm that it works


was (Author: grishick):
A straightforward patch moving retries logic from createMethod to executeMethod 
and a unit test to confirm that it works

 HttpServer maxRetries attributes seems like not being used as expected
 --

 Key: SOLR-6724
 URL: https://issues.apache.org/jira/browse/SOLR-6724
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 4.10.2
 Environment: OS X 10.9.5
 Java 1.7.0_60
Reporter: Márcio Furlani Carmona
Priority: Minor
 Attachments: SOLR-6724.patch


 Looks like maxRetries is being misused in the 
 org.apache.solr.client.solrj.impl.HttpSolrServer.createMethod(SolrRequest) 
 instead of being used in the executeMethod(HttpRequestBase,ResponseParser).
 In the current implementation the maxRetries is used in a loop that only 
 instantiates the HttpRequestBase but it doesn't effectively make any HTTP 
 request. Also the retries are made even in a successful instantiation  of the 
 HttpRequestBase as there's no break too.
 I notice there's also a catch for NoHttpResponseException but as no HTTP 
 request is made I guess it will never happen.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-7170) exceptions thrown by SolrJ are do not provide sufficient information to gracefully handle errors

[Greg Solovyev (JIRA)]

Greg Solovyev created SOLR-7170:
---

 Summary: exceptions thrown by SolrJ are do not provide sufficient 
information to gracefully handle errors
 Key: SOLR-7170
 URL: https://issues.apache.org/jira/browse/SOLR-7170
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: 4.10.3
Reporter: Greg Solovyev
Priority: Minor


Currently, exceptions thrown by SolrJ are do not provide sufficient information 
that would enable graceful error handling. Here are some examples:

When a Solr Collection does not exist, SolrJ throws ErrorCode.BAD_REQUEST with 
message Could not find collection:  or Could not find collection in zk: .  
The only part of the exception that hints to the type of problem is the 
message. However, a hardcoded text message is not a reliable point of data to 
be used in exception handling. It would be much cleaner if SolrJ expanded its 
library of Error Codes and used them to specify what type of error has 
occurred. E.g. :
ErrorCode.CANNOT_FIND_COLLECTION (for the above example)

ErrorCode.NO_LIVE_NODES (instead of just SolrServerException(No live 
SolrServers available to handle this request))

ErrorCode.BAD_RESPONSE (instead of just SolrServerException(Expected JSON 
object in response from ...)

etc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6637) Solr should have a way to restore a core

[Greg Solovyev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208425#comment-14208425
 ] 

Greg Solovyev commented on SOLR-6637:
-

I have been looking for this functionality, but with a slight twist where index 
files for the core need to be shipped over the network rather than provided on 
storage local to the Solr instance where the core is being restored. I have an 
implementation of CoreRestoreHandler that takes index files over HTTP as 
ContentStreams. Should I submit it to this ticket as a patch?

 Solr should have a way to restore a core
 

 Key: SOLR-6637
 URL: https://issues.apache.org/jira/browse/SOLR-6637
 Project: Solr
  Issue Type: Improvement
Reporter: Varun Thacker
 Attachments: SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, 
 SOLR-6637.patch, SOLR-6637.patch


 We have a core backup command which backs up the index. We should have a 
 restore command too. 
 This would restore any named snapshots created by the replication handlers 
 backup command.
 While working on this patch right now I realized that during backup we only 
 backup the index. Should we backup the conf files also? Any thoughts? I could 
 separate Jira for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-5987) Add collection to UpdateParams

[Greg Solovyev (JIRA)]

Greg Solovyev created SOLR-5987:
---

 Summary: Add collection to UpdateParams
 Key: SOLR-5987
 URL: https://issues.apache.org/jira/browse/SOLR-5987
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7.2
Reporter: Greg Solovyev
Priority: Trivial


CloudSolrServer currently references collection parameter using hard-coded 
string collection, instead of using a constant field. This does not break 
anything, but is just general code cleanness issue. It is also harder to figure 
out how to specify a specific collection to send an update to without looking 
into CloudSolrServer source code. If it was using UpdateParams.COLLECTION 
constant, it would have been possible to look at UpdateParams JavaDoc to figure 
this out.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

unsubscribe

[Greg Solovyev]