lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shad Storhaug (Jira)" <j...@apache.org>
Subject [jira] [Commented] (LUCENENET-602) Error using Lucene.Net.Facet 4.8.0-beta00005 with Xamarin.iOS
Date Thu, 31 Oct 2019 20:25:00 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964369#comment-16964369
] 

Shad Storhaug commented on LUCENENET-602:
-----------------------------------------

Stefano,

Thanks for the report. We used to use {{LruCache}} (or some similar class) and it was compatible
with the facet functionality, but we got some complaints about performance. {{LurchTable}}
was found to perform much better (on Windows, anyway), primarily due to the locking contention
that is present in {{LruCache}}. Therefore, using {{LruCache}} as-is for any platforms that
fully support {{LurchTable}} is not an acceptable trade-off due to the performance penalty.

Note that although no users have reported problems with it, this issue affects some parts
of Lucene.Net.QueryParser in addition to Lucene.Net.Facet.

I agree fixing the LRU cache is something that needs to be done but so far there hasn't been
enough information provided for us to fix it without taking a performance hit. Of course,
it would definitely help if our tests were setup to run on Xamarin.iOS so we have a way to
confirm that any change has a positive effect, which is something that is currently up-for-grabs
(see [LUCENENET-633|https://issues.apache.org/jira/browse/LUCENENET-633]). Adding testing
support should be simpler to do now that we are setup on Azure DevOps via YAML configuration.

If we cannot somehow patch {{LurchTable}} to make it work with Xamarin.iOS, the next best
option would be to detect when we are running on Xamarin.iOS and swap the implementation to
{{LruCache}} during initialization for only that case. I found some information [on this StackOverflow
answer|https://stackoverflow.com/a/48260863] (which coincidentally is one that I also answered)
that seems like it might be a way to detect that specific case, especially if you click through
to the related documents. So, it seems there is a way to detect {{Xamarin}} and a way to detect
{{Device.iOS}}, and hopefully combining the two methods should give us the specific behavior
we need to provide this swap only in the case where it is needed.

It would be extremely helpful if you could verify that the combination of the above methods
will indeed detect only Xamarin.iOS and not trigger on Xamarin in general or iOS in general.
It would be even more helpful if you could setup our tests to run on Xamarin.iOS and provide
tests we can run that confirm the platform detection will work. Do note that the general place
where we do platform detection is in [Lucene.Net.Util.Constants.cs|https://github.com/apache/lucenenet/blob/5c434545b31e8131485e00657b37685610358677/src/Lucene.Net/Util/Constants.cs].

The current thinking is to clean up all of our collections (including those that we have absorbed
from 3rd parties) and make them into 1st class features that can be used by end users (see
[LUCENENET-616|https://issues.apache.org/jira/browse/LUCENENET-616]). However, it goes beyond
that - we have also absorbed a handful of Java-like types that really need to be polished
and put into a separate, stable general library that can be utilized by Lucene.NET's dependencies
to share interfaces, collections, and other compatibility functionality that hasn't yet debuted
in the .NET ecosystem. We are sometimes running into issues where we cannot pass a type in
library A to library B because there is no common interface in the BCL to pass it like there
is in Java.

While it would certainly be better to submit PRs and get the collection libraries up to speed
as far as behavior, interfaces, and platform compatibility is concerned, I am becoming convinced
that it is not likely going to happen. I [reported back in 2016 to the maintainers of C5 that
their sets don't support {{ISet<T>}}|https://github.com/sestoft/C5/issues/53] and although
they thought it might be a good idea to do, it still hasn't been done. I recently started
working on a PR, but found that C5 would require breaking API changes to their dictionaries
(or alternatively a compatibility wrapper) just to make them compatible with common collection
interfaces in the BCL. Furthermore, they are already dropping support for .NET Framework 4.5
and .NET Standard 1.x. So, we are likely going to have to build our own library of collections
in order to get the level of compatibility, stability, and most importantly end-user usability
we will need.

Anyway, any assistance that is provided to help us get to the bottom of this without it costing
us dearly in terms of performance would be appreciated.

> Error using Lucene.Net.Facet 4.8.0-beta00005  with Xamarin.iOS
> --------------------------------------------------------------
>
>                 Key: LUCENENET-602
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-602
>             Project: Lucene.Net
>          Issue Type: Bug
>          Components: Lucene.Net.Facet
>    Affects Versions: Lucene.Net 4.8.0
>         Environment: Xamarin Forms 3.0.0.561731
> Ios 10.3.3 and Higher
> Lucene.Net.Facet 4.8.0-beta00005
>            Reporter: Enrico Caltran
>            Priority: Minor
>              Labels: AOT, Xamarin.iOS, lucene.net.facet
>             Fix For: Lucene.Net 4.8.0
>
>         Attachments: AppTestLucene.zip, image-2019-08-08-02-26-40-582.png
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> I'm using Lucene.Net.Facet 4.8.0-beta00005 in a big Xamarin project.
> +With Xamarin.Android and Xamarin.UWP it's all right.+
> *+But With Xamarin.iOS on device (Ipad)+*, i'm receiving this error:
>  _Attempting to JIT compile method 'Lucene.Net.Support.LurchTable2&lt;Lucene.Net.Facet.Taxonomy.FacetLabel,
Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader/Int32Class&gt;:InternalInsert&lt;Lucene.Net.Support.LurchTable2/Add2Info<Lucene.Net.Facet.Taxonomy.FacetLabel,
Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader/Int32Class>> (int,Lucene.Net.Facet.Taxonomy.FacetLabel,int&,Lucene.Net.Support.LurchTable`2/Add2Info<Lucene.Net.Facet.Taxonomy.FacetLabel,
Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader/Int32Class>&)' while running
in aot-only mode. See [https://developer.xamarin.com/guides/ios/advanced_topics/limitations/]
for more information._
> _{color:#d04437}at Lucene.Net.Support.LurchTable2[TKey,TValue].Insert[T] (TKey key, T&amp;
value) &lt;0x2570f48 + 0x000e0&gt; in &lt;063e095c95d945a4ace32ab83d1227eb#2ae0fea9ea4eacaef83bf2e9713bb8ea&gt;:0
at (wrapper unknown) System.Object.gsharedvt_in() at Lucene.Net.Support.LurchTable2[TKey,TValue].AddOrUpdate
(TKey key, TValue addValue, Lucene.Net.Support.KeyValueUpdate2[TKey,TValue] fnUpdate) &lt;0x232824c
+ 0x0013b&gt; in &lt;063e095c95d945a4ace32ab83d1227eb#2ae0fea9ea4eacaef83bf2e9713bb8ea&gt;:0
at Lucene.Net.Facet.Taxonomy.LRUHashMap2[TKey,TValue].Put (TKey key, TValue value) <0x2c487f8
+ 0x0015b> in <79d3a7b905954d0993025c09c5d087ce#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
at Lucene.Net.Facet.Taxonomy.Directory.DirectoryTaxonomyReader.GetOrdinal (Lucene.Net.Facet.Taxonomy.FacetLabel
cp) <0x2c51970 + 0x0019b> in <79d3a7b905954d0993025c09c5d087ce#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
at Lucene.Net.Facet.Taxonomy.Int32TaxonomyFacets.GetTopChildren{color} (System.Int32 topN,
System.String dim, System.String[] path) <0x2c481dc + 0x0008f> in <79d3a7b905954d0993025c09c5d087ce#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
at Login.MyMB.Lucene.Client.LuceneArticoliSearcher.GetListaArticoloXRicercaAvanzataConRicercaSemplice
(System.Collections.Generic.List1[T] listParametri) &lt;0x224add0 + 0x001bb&gt; in
&lt;8f49891e0f0546e185aba7424d294ef7#2ae0fea9ea4eacaef83bf2e9713bb8ea&gt;:0 at Login.MyMB.Lucene.Client.LuceneArticoliSearcher.GetListaArticoloConRicercaSemplice
(System.Collections.Generic.List1[T] listParametri) <0x224afbc + 0x0009f> in <8f49891e0f0546e185aba7424d294ef7#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
at MyMB.Forms.RicercaLucene.RicercaArticoloLucene.GetListaArticoliXRicercaSemplice (Login.MyMB.Interface.IAmbiente
ambiente, Login.MyMB.Lucene.Client.LuceneArticoliSearcher las, System.Collections.Generic.List`1[T]
ListParametri, System.Boolean isAbilitataRicercaBarcode) <0xe47fc0 + 0x000e7> in <f1bb3149abe145459612794f1a096634#2ae0fea9ea4eacaef83bf2e9713bb8ea>:0
..............................._
> At the link [https://docs.microsoft.com/it-it/xamarin/ios/internals/limitations] , I
found the problem cause (I suppose...):
> _Value types as Dictionary Keys Using a value type as a Dictionary<TKey, TValue>
key is problematic, as the default Dictionary constructor attempts to use EqualityComparer<TKey>.Default.
EqualityComparer<TKey>.Default, in turn, attempts to use Reflection to instantiate a
new type which implements the IEqualityComparer<TKey> interface. This works for reference
types (as the reflection+create a new type step is skipped), but for value types it crashes
and burns rather quickly once you attempt to use it on the device. Workaround: Manually implement
the IEqualityComparer<TKey> interface in a new type and provide an instance of that
type to the Dictionary<TKey, TValue> (IEqualityComparer<TKey>) constructor._
> So, what can I do? Thank you in advance, Enrico Caltran +393357485560 [enrico.caltran@timegroup.it|mailto:enrico.caltran@timegroup.it]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message