[
https://issues.apache.org/jira/browse/SOLR-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15166522#comment-15166522
]
Noble Paul edited comment on SOLR-8349 at 2/25/16 1:37 AM:
-----------------------------------------------------------
One problem I see with the patch is, with decoding the bytebuffer in two
different ways . What if core1 has decoder1 and core2 has decoder2. Then the
second call gets the output of first decoder. That's why I kept a map
internally so that it is possible to deal with that usecase. It may be unusual
to do so , but, for sake of correctness we have to do it
was (Author: noble.paul):
One problem I see with the patch is, with decoding the object in two different
ways . What if core1 has decoder1 and core2 has decoder2. Then the second call
gets the output of first decoder. That's why I kept a map internally so that it
is possible to deal with that usecase. It may be unusual to do so , but, for
sake of correctness we have to do it
> Allow sharing of large in memory data structures across cores
> -------------------------------------------------------------
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
> Issue Type: Improvement
> Components: Server
> Affects Versions: 5.3
> Reporter: Gus Heck
> Assignee: Noble Paul
> Attachments: SOLR-8349.patch, SOLR-8349.patch, SOLR-8349.patch,
> SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large
> dictionary or other in-memory structure. When multiple cores are loaded with
> identical configurations utilizing this large in memory structure, each core
> holds it's own copy in memory. This has been noted in the past and a specific
> case reported in SOLR-3443. This patch provides a generalized capability, and
> if accepted, this capability will then be used to fix SOLR-3443.
--
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
