[jira] [Created] (IGNITE-12830) REST API - Return the right HTTP status code
Koala Lam created IGNITE-12830:
--
Summary: REST API - Return the right HTTP status code
Key: IGNITE-12830
URL: https://issues.apache.org/jira/browse/IGNITE-12830
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7.6
Reporter: Koala Lam
For example, when the cluster is not in running stage, receiving a REST request
would still return a 200 HTTP status code with below response payload :
{
successStatus: 1,
sessionToken: null,
error: "Failed to handle request (received request while stopping grid).",
response: null
}
Should REST API return a non-2xx status code instead?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12829) Custom GROUP_CONCAT separator is ignored
Alexey Kukushkin created IGNITE-12829: - Summary: Custom GROUP_CONCAT separator is ignored Key: IGNITE-12829 URL: https://issues.apache.org/jira/browse/IGNITE-12829 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.8 Reporter: Alexey Kukushkin Assignee: Alexey Kukushkin According to [https://apacheignite-sql.readme.io/docs/group_concat] GROUP_CONCAT supports user-defined separator. Actually it is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12828) Intermittent "Failed to notify direct custom event listener" exception on node shutdown
Alexey Kukushkin created IGNITE-12828: - Summary: Intermittent "Failed to notify direct custom event listener" exception on node shutdown Key: IGNITE-12828 URL: https://issues.apache.org/jira/browse/IGNITE-12828 Project: Ignite Issue Type: Bug Affects Versions: 2.8 Reporter: Alexey Kukushkin Assignee: Alexey Kukushkin +*Reproducer*+: Run a server node Run a client node that: * Creates cache "cache1" * Deploys a grid service that starts a continuous query against "cache1" in method init() * Leaves the cluster +*Actual result*+ Intermittent exception in the client node: [16:54:38,758][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager] Failed to notify direct custom event listener: StartRoutineDiscoveryMessage [startReqData=StartRequestData [prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@63ae71a9, clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler [returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@594bf5b8, cacheName=CALC_REQUESTS, rmtFilter=null, rmtFilterDep=null, internal=false, notifyExisting=false, oldValRequired=true, sync=false, ignoreExpired=true, taskHash=0, skipPrimaryCheck=false, locOnly=false, keepBinary=true, ackBuf=null, cacheId=-1608655250, initTopVer=null, nodeLeft=false, ignoreClsNotFound=false, nodeId=null, routineId=null], bufSize=1, interval=0, autoUnsubscribe=true], keepBinary=true, routineId=021dd2ce-3d8a-41c1-a4d0-b625ea1284f4] java.lang.NullPointerException at org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82) at org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193) at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:722) at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601) at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2683) at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2721) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at java.lang.Thread.run(Thread.java:745) [16:54:39,725][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager] Failed to notify direct custom event listener: StartRoutineDiscoveryMessage [startReqData=StartRequestData [prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@7462c96c, clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler [returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@6451dd70, cacheName=DISTRIBUTED_REQUESTS, rmtFilter=null, rmtFilterDep=null, internal=false, notifyExisting=false, oldValRequired=true, sync=false, ignoreExpired=true, taskHash=0, skipPrimaryCheck=false, locOnly=false, keepBinary=true, ackBuf=null, cacheId=1419803136, initTopVer=null, nodeLeft=false, ignoreClsNotFound=false, nodeId=null, routineId=null], bufSize=1, interval=0, autoUnsubscribe=true], keepBinary=true, routineId=1fca5f04-d220-49ac-850a-0d4527e22eef] java.lang.NullPointerException at org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82) at org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202) at org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193) at
[jira] [Created] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
Alexey Kukushkin created IGNITE-12827:
-
Summary: OutOfMemory exception when calling grid service from .NET
with user type array parameter
Key: IGNITE-12827
URL: https://issues.apache.org/jira/browse/IGNITE-12827
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin
Calling a grid service from .NET with a parameter of user type array leads to
Java OutOfMemory exception.
+*Reproducer*+:
* Limit JVM heap with 128 MB.
* Create a .NET or Java service with a parameter of type
*array of* Parameter {
Id: int,
*array of* ParameterValue {
PeriodId: int,
Value: double?
}
}
* Call service with an array of 200 Parameters
+*Expected*+:
128 MB of heap must be enough to call Java or .NET service with 200 Parameters.
+*Actual*+:
Java OutOfMemory exception on 21st Parameter
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12826) Poor JDBC Cache Store performance due to default fetch size
Alexey Kukushkin created IGNITE-12826: - Summary: Poor JDBC Cache Store performance due to default fetch size Key: IGNITE-12826 URL: https://issues.apache.org/jira/browse/IGNITE-12826 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.8 Reporter: Alexey Kukushkin Assignee: Alexey Kukushkin JDBC "fetchSize" parameter specifies the number of rows to be fetched from the database when additional rows are needed. For most drivers it is 10 by default. Larger fetchSize can significantly improve performance due to less network roundtrips (at expense of greater memory consumption). For some reason out-of-box JDBC POJO Cache Store uses default fetchSize in the loadCache method implementation. We have very poor loadCache performance when loading large amount of data from Oracle with the default fetchSize of 10. We tried setting fetchSize to 20K and that improved performance 40 times. We need to use JdbcDialect#fetchSize in the loadCache implementation so that users could implement a custom JdbcDialect to configure fetchSIze. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-12825: -- Labels: sbcf (was: ) > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: sbcf > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-12825: -- Description: Java and .NET use different calendars for dates serialization. That results in some dates written using Java API deserialized into different dates using .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. Java and .NET API must use same calendars for dates serialization. +*Note:*+ Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored locally that could be manually updated using Timezone Updater Tool ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) .NET uses its own calendars that cannot be manually updated. For all the Java/.NET calendar differences I saw the Java version was valid and .NET version was not. We need to use IANA time zone database in .NET as well and, if possible, provide a mechanism to update the time zone database was: Java and .NET use different calendars for dates serialization. That results in some dates written using Java API deserialized into different dates using .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. Java and .NET API must use same calendars for dates serialization. +*Note:*+ Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored locally that could be manually updated using Timezone Updater Tool ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) .NET uses its own calendars that cannot be manually updated. All the Java/.NET calendar differences I saw were > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12825) Serialize Java and .NET dates using same calendars
Alexey Kukushkin created IGNITE-12825: - Summary: Serialize Java and .NET dates using same calendars Key: IGNITE-12825 URL: https://issues.apache.org/jira/browse/IGNITE-12825 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.8 Reporter: Alexey Kukushkin Assignee: Alexey Kukushkin Java and .NET use different calendars for dates serialization. That results in some dates written using Java API deserialized into different dates using .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. Java and .NET API must use same calendars for dates serialization. +*Note:*+ Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored locally that could be manually updated using Timezone Updater Tool ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) .NET uses its own calendars that cannot be manually updated. All the Java/.NET calendar differences I saw were -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12824) Change .NET API to write Dates in interoperable format by default
Alexey Kukushkin created IGNITE-12824: - Summary: Change .NET API to write Dates in interoperable format by default Key: IGNITE-12824 URL: https://issues.apache.org/jira/browse/IGNITE-12824 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.8 Reporter: Alexey Kukushkin Assignee: Alexey Kukushkin Presently BinaryReflectiveSerializer serialises .NET dates Ignite objects by default. This could be changed by either setting BinaryReflectiveSerializer.ForceTimestamp property to "true" or adding "QuerySqlField" attribute to Date fields. I have multiple Ignite/GridGain users using this functionality and all of them are confused with this default behavior. Let's see if we can change the default behavior to save .NET dates in interoperable Ignite TIMESTAMP format, converting them to UTC dates inside BinaryReflectiveSerializer so that the users do not have to do the ToUniversalDate conversion manually. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12823) .NET client cannot find service method with user type array parameter
Alexey Kukushkin created IGNITE-12823:
-
Summary: .NET client cannot find service method with user type
array parameter
Key: IGNITE-12823
URL: https://issues.apache.org/jira/browse/IGNITE-12823
Project: Ignite
Issue Type: Bug
Components: platforms
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin
*+Setup+*
* Java service with a method having an array of user types as a parameters,
for example, caclulate(Parameter[] params)
*+Actions+*
* .NET client calls the GG Java service, for example,
ignite.GetServices().GetServiceProxy().calculate(new[] \{new
Parameter()});
*+Expected+*
* The service method is called
*+Actual+*
* Exception "Could not find proxy method 'calculate' in class ICalculator"
*+Workaround+*
* Replace array of user types with array of objects in the service methods
signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12702) Print warning when a cache value contains @AffinityKeyMapped annotation
[
https://issues.apache.org/jira/browse/IGNITE-12702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kartik Somani reassigned IGNITE-12702:
--
Assignee: Kartik Somani
> Print warning when a cache value contains @AffinityKeyMapped annotation
> ---
>
> Key: IGNITE-12702
> URL: https://issues.apache.org/jira/browse/IGNITE-12702
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis Mekhanikov
>Assignee: Kartik Somani
>Priority: Major
> Labels: newbie
>
> Consider the following code snippet:
> {code:java}
> public class WrongAffinityExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("employees");
> EmployeeKey key = new EmployeeKey(1);
> EmployeeValue value = new EmployeeValue(1, "Denis");
> cache.put(key, value);
> }
> public static class EmployeeKey {
> private int id;
> public EmployeeKey(int id) {
> this.id = id;
> }
> }
> public static class EmployeeValue {
> @AffinityKeyMapped
> int departmentId;
> String name;
> public EmployeeValue(int departmentId, String name) {
> this.departmentId = departmentId;
> this.name = name;
> }
> }
> }
> {code}
> Note, that {{EmployeeValue}} contains an {{@AffinityKeyMapped}} annotation,
> which doesn't have any effect, since it's specified in a value, and not in a
> key.
> Such mistake is simple to make and pretty hard to track down.
> This configuration should trigger a warning message printed in log to let
> the user know that this affinity key configuration is not applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12822) .NET: Build fails on Xamarin
[
https://issues.apache.org/jira/browse/IGNITE-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064227#comment-17064227
]
Pavel Tupitsyn commented on IGNITE-12822:
-
The fix is probably to build a proper netstandard2.0 assembly and include it in
NuGet package instead of current hack.
> .NET: Build fails on Xamarin
>
>
> Key: IGNITE-12822
> URL: https://issues.apache.org/jira/browse/IGNITE-12822
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.9
>
>
> * Create new Xamarin Forms app in Visual Studio
> * Add reference to Apache.Ignite NuGet package
> * Try to rebuild all:
> {code}
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
> error XA2002: Can not resolve reference: `System.Configuration`, referenced
> by `Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
> `System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
> {code}
> Xamarin does not include System.Configuration assembly.
> The workaround is to manually add a reference to System.Configuration from
> anywhere (it is not used at runtime, we just need to satisfy the build):
> {code}
>
>
> ..\..\bin\System.Configuration.dll
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12822) .NET: Build fails on Xamarin
[
https://issues.apache.org/jira/browse/IGNITE-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12822:
Fix Version/s: (was: 2.8.1)
2.9
> .NET: Build fails on Xamarin
>
>
> Key: IGNITE-12822
> URL: https://issues.apache.org/jira/browse/IGNITE-12822
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.9
>
>
> * Create new Xamarin Forms app in Visual Studio
> * Add reference to Apache.Ignite NuGet package
> * Try to rebuild all:
> {code}
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
> error XA2002: Can not resolve reference: `System.Configuration`, referenced
> by `Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
> `System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
> {code}
> Xamarin does not include System.Configuration assembly.
> The workaround is to manually add a reference to System.Configuration from
> anywhere (it is not used at runtime, we just need to satisfy the build):
> {code}
>
>
> ..\..\bin\System.Configuration.dll
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12822) .NET: Build fails on Xamarin
[
https://issues.apache.org/jira/browse/IGNITE-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12822:
Ignite Flags: Release Notes Required
Release Note: .NET Thin: Add Xamarin support
> .NET: Build fails on Xamarin
>
>
> Key: IGNITE-12822
> URL: https://issues.apache.org/jira/browse/IGNITE-12822
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.8.1
>
>
> * Create new Xamarin Forms app in Visual Studio
> * Add reference to Apache.Ignite NuGet package
> * Try to rebuild all:
> {code}
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
> error XA2002: Can not resolve reference: `System.Configuration`, referenced
> by `Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
> `System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
> {code}
> Xamarin does not include System.Configuration assembly.
> The workaround is to manually add a reference to System.Configuration from
> anywhere (it is not used at runtime, we just need to satisfy the build):
> {code}
>
>
> ..\..\bin\System.Configuration.dll
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12822) .NET: Build fails on Xamarin
Pavel Tupitsyn created IGNITE-12822:
---
Summary: .NET: Build fails on Xamarin
Key: IGNITE-12822
URL: https://issues.apache.org/jira/browse/IGNITE-12822
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.8.1
* Create new Xamarin Forms app in Visual Studio
* Add reference to Apache.Ignite NuGet package
* Try to rebuild all:
{code}
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
error XA2002: Can not resolve reference: `System.Configuration`, referenced by
`Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
`System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
{code}
Xamarin does not include System.Configuration assembly.
The workaround is to manually add a reference to System.Configuration from
anywhere (it is not used at runtime, we just need to satisfy the build):
{code}
..\..\bin\System.Configuration.dll
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12822) .NET: Build fails on Xamarin
[
https://issues.apache.org/jira/browse/IGNITE-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12822:
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Build fails on Xamarin
>
>
> Key: IGNITE-12822
> URL: https://issues.apache.org/jira/browse/IGNITE-12822
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.8.1
>
>
> * Create new Xamarin Forms app in Visual Studio
> * Add reference to Apache.Ignite NuGet package
> * Try to rebuild all:
> {code}
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
> error XA2002: Can not resolve reference: `System.Configuration`, referenced
> by `Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
> `System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
> {code}
> Xamarin does not include System.Configuration assembly.
> The workaround is to manually add a reference to System.Configuration from
> anywhere (it is not used at runtime, we just need to satisfy the build):
> {code}
>
>
> ..\..\bin\System.Configuration.dll
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
