[jira] [Created] (IGNITE-14494) .NET: Problem with collection de/serialization
Yaroslav Molochkov created IGNITE-14494: --- Summary: .NET: Problem with collection de/serialization Key: IGNITE-14494 URL: https://issues.apache.org/jira/browse/IGNITE-14494 Project: Ignite Issue Type: Bug Reporter: Yaroslav Molochkov Attachments: UnitTest.cs Reproducer is attached. Basically the problem surfaces when you call service's method via proxy. The method is supposed to return a collection type result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14214) Incorrect merge query when using oracle dialect
Yaroslav Molochkov created IGNITE-14214:
---
Summary: Incorrect merge query when using oracle dialect
Key: IGNITE-14214
URL: https://issues.apache.org/jira/browse/IGNITE-14214
Project: Ignite
Issue Type: Bug
Reporter: Yaroslav Molochkov
Assignee: Yaroslav Molochkov
If table contains only keys (e.g. relationship table) then returned query
contains empty update fields and resulting syntax is incorrect.
Consider the following example:
org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts key
and val collections. The problem is relevant if val collection is empty.
{code:java}
return String.format("MERGE INTO %s t" +
" USING (SELECT %s FROM dual) v" +
" ON %s" +
" WHEN MATCHED THEN" +
" UPDATE SET %s" +
" WHEN NOT MATCHED THEN" +
" INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols, colsLst,
valuesCols);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14071) .NET: Ignite messaging interoperability
Yaroslav Molochkov created IGNITE-14071: --- Summary: .NET: Ignite messaging interoperability Key: IGNITE-14071 URL: https://issues.apache.org/jira/browse/IGNITE-14071 Project: Ignite Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Yaroslav Molochkov Attachments: MessageHandler.java, Test.cs Currently IGNITE-10075 doesn't provide all needed type interoperability thus ignite messaging works somewhat quirky. Thanks to [~kukushal] for pointing that out. Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14020) .NET: Exceptions interoperability
Yaroslav Molochkov created IGNITE-14020: --- Summary: .NET: Exceptions interoperability Key: IGNITE-14020 URL: https://issues.apache.org/jira/browse/IGNITE-14020 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.9.1 Reporter: Yaroslav Molochkov Currently it's cumbersome to make use of .net exceptions because an exception is propagated from java-side reflection or local call hence we will see lots of unrelated and, more often than not, useless frames. To avoid that the exception from the .net side needs to have registered java counterpart so we can see the exact problem clearly. I propose to make exceptions interoperable just like types. We can resolve types between environments up to a namespace. It would be very useful to do the same with exceptions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
Yaroslav Molochkov created IGNITE-13949:
---
Summary: Insufficient synchronisation in
PartitionUpdateCounterTrackingImpl
Key: IGNITE-13949
URL: https://issues.apache.org/jira/browse/IGNITE-13949
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Yaroslav Molochkov
Assignee: Yaroslav Molochkov
Right now
org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
has 2 AtomicLong variables, cntr and reserveCntr, but there are some methods,
that are unsynchronised, e.g. next:
{code:java}
@Override public long next() {
long next = cntr.incrementAndGet();
reserveCntr.set(next);
return next;
} {code}
Even though both are AtomicLong, operation like "get then set" is a composite
one and should be atomic in the context of an object that holds these variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13897) .NET Service can't assign correct type to passed array parameters
Yaroslav Molochkov created IGNITE-13897:
---
Summary: .NET Service can't assign correct type to passed array
parameters
Key: IGNITE-13897
URL: https://issues.apache.org/jira/browse/IGNITE-13897
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.9
Reporter: Yaroslav Molochkov
Assignee: Yaroslav Molochkov
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method
'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
Method)
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Service interface itself looks like this:
{code:java}
public interface SomeService
{
int processSomething(int foo, Parameter[] parameters);
}
public class Parameter
{
private int id;
private ParamValue[] _values;
public Parameter(int id, ParamValue[] _values)
{
this.id = id;
this._values = _values;
}
}
public class ParamValue
{
private int id;
private double val;
public ParamValue(int id, double val)
{
this.id = id;
this.val = val;
}
}
{code}
And the call to the service:
{code:java}
var svc = igniteServices.GetServiceProxy(name, false);
var result = svc.processSomething(id, parameters);
{code}
Now, if this is a server node then call is successful. If the call goes from
the client node then we'll get the error above.
Fix in IGNITE-12823 addresses particular code execution path where the
execution flow goes through PlatformServices class. Yet in this case our code
goes through PlatformAbstractService. I think that the fix of casting arrays
should be positioned a little bit lower in the call stack (or higher in code
hierarchy) so all execution paths are covered simultaneously.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13884) Merge docs into 2.9.1
Yaroslav Molochkov created IGNITE-13884: --- Summary: Merge docs into 2.9.1 Key: IGNITE-13884 URL: https://issues.apache.org/jira/browse/IGNITE-13884 Project: Ignite Issue Type: Bug Components: documentation Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13876) Update documentation for 2.9.1 release
Yaroslav Molochkov created IGNITE-13876: --- Summary: Update documentation for 2.9.1 release Key: IGNITE-13876 URL: https://issues.apache.org/jira/browse/IGNITE-13876 Project: Ignite Issue Type: Bug Components: documentation Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov The update should reflect changes made to system views(BINARY_METADATA and DISTRIBUTED_METASTORAGE) and metrics (RebalancingPartitionsTotal) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13839) TeamCity release assembly git issue
Yaroslav Molochkov created IGNITE-13839:
---
Summary: TeamCity release assembly git issue
Key: IGNITE-13839
URL: https://issues.apache.org/jira/browse/IGNITE-13839
Project: Ignite
Issue Type: Bug
Reporter: Yaroslav Molochkov
Currently there is a problem with script "vote_1[git]create_rc_tag" execution:
{code}
error: object directory /opt/buildagent/system/git/git-BF1D6845.git/objects
does not exist; check .git/objects/info/alternates
error: refs/heads/ignite-2.9 does not point to a valid object!
error: refs/remotes/origin/ignite-2.9 does not point to a valid object!
error: refs/tags/1.1.3 does not point to a valid object!
{code}
The problem is with mirroring option for TC VCS root.
Possible solution: redesign release build to require native checked out
repository, not mirrored one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13806) Merge release notes for 2.9.1 into master
Yaroslav Molochkov created IGNITE-13806: --- Summary: Merge release notes for 2.9.1 into master Key: IGNITE-13806 URL: https://issues.apache.org/jira/browse/IGNITE-13806 Project: Ignite Issue Type: Task Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13323) GridDhtPartitionsExchangeFuture logging improvements
Yaroslav Molochkov created IGNITE-13323: --- Summary: GridDhtPartitionsExchangeFuture logging improvements Key: IGNITE-13323 URL: https://issues.apache.org/jira/browse/IGNITE-13323 Project: Ignite Issue Type: Improvement Affects Versions: 2.8.1 Reporter: Yaroslav Molochkov Firstly, logging in said class should be improved to address possible cluster topology/connectivity issues: org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#processFullMessage, upon entering that method and before critical section begins we should log that at info level. This way we won't have to speculate if thread is waiting on a lock to not.(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#mux) Secondly, org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#sendAllPartitions. Logging should reflect the amount of nodes that should receive messages (collection that is sent to said method) and the amount of nodes that should receive the message (or, in other words, we successfully managed to send the message to a particular node, then sum it up). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13322) Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe
Yaroslav Molochkov created IGNITE-13322: --- Summary: Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe Key: IGNITE-13322 URL: https://issues.apache.org/jira/browse/IGNITE-13322 Project: Ignite Issue Type: Improvement Reporter: Yaroslav Molochkov Currently org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#srvNodes reference is initialised to the ArrayList, which is not a thread-safe implementation. Solution to this ticket must guarantee thread-safety of the srvNodes collection. -- This message was sent by Atlassian Jira (v8.3.4#803005)
