[jira] [Created] (IGNITE-7519) DataStreamer suppresses exceptions in IsolatedUpdater
Ilya Kasnacheev created IGNITE-7519:
---
Summary: DataStreamer suppresses exceptions in IsolatedUpdater
Key: IGNITE-7519
URL: https://issues.apache.org/jira/browse/IGNITE-7519
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.5
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
{code:java}
catch (IgniteCheckedException ex) {
IgniteLogger log = cache.unwrap(Ignite.class).log();
U.error(log, "Failed to set initial value for cache
entry: " + e, ex);
}{code}
This is problematic because the problem is never reported to DataStreamer so it
will be close()d with no exceptions and data loss!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7476) Server node will join with failure gathering metrics
Ilya Kasnacheev created IGNITE-7476:
---
Summary: Server node will join with failure gathering metrics
Key: IGNITE-7476
URL: https://issues.apache.org/jira/browse/IGNITE-7476
Project: Ignite
Issue Type: Bug
Reporter: Ilya Kasnacheev
Sometimes server node will fail with the following trace:
{code:java}
SEVERE: TcpDiscoverSpi's message worker thread failed abnormally. Stopping the
node in order to prevent cluster wide instability.
java.lang.NullPointerException
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1149)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMetricsUpdateMessage(ServerImpl.java:5022)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2690)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2491)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6675)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2574)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62){code}
Two problems here:
* Uncaught exception in cacheMetrics() leads to unconditional failure of node,
because it happens to be in discovery thread. Should probably wrap all
non-trivial code include try-catch.
* Lack of proper locking when destroying cache (see also IGNITE-6423 and
IGNITE-7165)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7474) Exception on accessing sys cache when node joins topology with service
Ilya Kasnacheev created IGNITE-7474:
---
Summary: Exception on accessing sys cache when node joins topology
with service
Key: IGNITE-7474
URL: https://issues.apache.org/jira/browse/IGNITE-7474
Project: Ignite
Issue Type: Bug
Components: compute
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
Sometimes when node joins to a cluster with service configured, it will get the
following exception:
{code:java}
Exception in thread "sys-#1071" java.lang.IllegalArgumentException: Cache is
not configured: ignite-sys-cache
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3423)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:770)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:742)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:696)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1110)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1600(GridContinuousProcessor.java:103)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$7.onMessage(GridContinuousProcessor.java:755)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2751)
at
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1515)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1484)
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}
Seems to be a race condition. I will try to provide test case later.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7366) Affinity assignment exception in service processor during multiple nodes join
Ilya Kasnacheev created IGNITE-7366:
---
Summary: Affinity assignment exception in service processor during
multiple nodes join
Key: IGNITE-7366
URL: https://issues.apache.org/jira/browse/IGNITE-7366
Project: Ignite
Issue Type: Bug
Components: compute
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
When two nodes which are deploying services join at the same time, and
exception is observed:
{code}
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:514)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1771)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1958)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{code}
This may be caused by exchange merges. There are 4 nodes joining topology. When
nodes 3 and 4 join at the same time, exchanges for [3, 0] and [4, 0] are
merged. But, TopologyListener in service processor is notified about topVer [3,
0], for which there is no affinity because exchange has already moved forward
to [4, 0].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7363) Inconsistent millis in java.util.Date when retrieved in SELECT query
Ilya Kasnacheev created IGNITE-7363: --- Summary: Inconsistent millis in java.util.Date when retrieved in SELECT query Key: IGNITE-7363 URL: https://issues.apache.org/jira/browse/IGNITE-7363 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.3 Reporter: Ilya Kasnacheev Attachments: 19222.zip ~ when querying for java.util.Date field in SELECT query it returns a java.sql.Timestamp, and when getTime() on that Timestamp is called it returns different milliseconds value than in original java.util.Date, in case Time Zone is different on client and on server. Using get() the correct java.util.Date is obtained. Please see reproducer, kudos http://apache-ignite-users.70518.x6.nabble.com/Date-type-field-in-select-query-is-returning-wrong-value-when-Time-zones-of-Ignite-Client-and-Servert-tc19222.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7356) IgfsImpl.stop(cancel: false) should not cancel batches
Ilya Kasnacheev created IGNITE-7356:
---
Summary: IgfsImpl.stop(cancel: false) should not cancel batches
Key: IGNITE-7356
URL: https://issues.apache.org/jira/browse/IGNITE-7356
Project: Ignite
Issue Type: Wish
Components: igfs
Affects Versions: 2.4
Reporter: Ilya Kasnacheev
Priority: Minor
Currently, in IgfsImpl.stop(), cancel parameter is not used, and all batches
are cancelled regardless:
{code}
for (IgfsFileWorkerBatch batch : workerMap.values())
batch.cancel();
{code}
I imagine, if cancel == false, we should await() batches which are finishing(),
as per await(). WDYT?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7264) Caches with forward slash "/" in names cause problems for PDS
Ilya Kasnacheev created IGNITE-7264: --- Summary: Caches with forward slash "/" in names cause problems for PDS Key: IGNITE-7264 URL: https://issues.apache.org/jira/browse/IGNITE-7264 Project: Ignite Issue Type: Bug Components: cache, persistence Affects Versions: 2.3 Reporter: Ilya Kasnacheev If I am to create cache with name "caches/1", there's no immediate error, but nodes fail when trying to rejoin topology with storage already initialized. I think there should be an immediate exception in case persistence is enabled for such case. Moreover, I suggest first trying to create directory, then making sure it was created and that dir.parent == expected parent directory. Because on Windows there are more restrictions on FS file names, etc... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7233) Problems with classpath on Windows when IGNITE_HOME contains spaces
Ilya Kasnacheev created IGNITE-7233:
---
Summary: Problems with classpath on Windows when IGNITE_HOME
contains spaces
Key: IGNITE-7233
URL: https://issues.apache.org/jira/browse/IGNITE-7233
Project: Ignite
Issue Type: Bug
Affects Versions: 2.3
Environment: Windows, cmd, batch files
Reporter: Ilya Kasnacheev
{code}
C:\releases> cd "apache-ignite-fabric-2.3.0 bin"
REM note the white space in folder name ^
C:\releases\apache-ignite-fabric-2.3.0 bin>set
IGNITE_HOME="C:\releases\apache-ignite-fabric-2.3.0 bin"
C:\releases\apache-ignite-fabric-2.3.0 bin>bin\ignite.bat
%IGNITE_HOME%\config\default.xml
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
Error: Could not find or load main class
bin\libs\*;C:\releases\apache-ignite-fabric-2.3.0\*
Error: Could not find or load main class
bin\libs\*;C:\releases\apache-ignite-fabric-2.3.0\*
bin\ignite.bat, WARN: Failed to resolve JMX host. JMX will be disabled.
class org.apache.ignite.IgniteException: Failed to create Ignite component
(consider adding ignite-spring module to classpath) [component=SPRING,
cls=org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl]
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
at org.apache.ignite.Ignition.start(Ignition.java:350)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to create
Ignite component (consider adding ignite-spring module to classpath)
[component=SPRING,
cls=org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl]
at
org.apache.ignite.internal.IgniteComponentType.componentException(IgniteComponentType.java:320)
at
org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:296)
at
org.apache.ignite.internal.IgniteComponentType.create(IgniteComponentType.java:207)
at
org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:671)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
at org.apache.ignite.Ignition.start(Ignition.java:347)
... 1 more
Caused by: java.lang.ClassNotFoundException:
org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at
org.apache.ignite.internal.IgniteComponentType.create0(IgniteComponentType.java:282)
... 8 more
Failed to start grid: Failed to create Ignite component (consider adding
ignite-spring module to classpath) [component=SPRING,
cls=org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl]
Note! You may use 'USER_LIBS' environment variable to specify your classpath.
Press any key to continue . . .
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7197) Premature access to services() causes NullPointerException
Ilya Kasnacheev created IGNITE-7197:
---
Summary: Premature access to services() causes NullPointerException
Key: IGNITE-7197
URL: https://issues.apache.org/jira/browse/IGNITE-7197
Project: Ignite
Issue Type: Bug
Components: managed services
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
{code}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceEntries(GridServiceProcessor.java:1289)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceDescriptors(GridServiceProcessor.java:762)
at
org.apache.ignite.internal.IgniteServicesImpl.serviceDescriptors(IgniteServicesImpl.java:203)
at
org.apache.ignite.internal.visor.service.VisorServiceTask$VisorServiceJob.run(VisorServiceTask.java:60)
at
org.apache.ignite.internal.visor.service.VisorServiceTask$VisorServiceJob.run(VisorServiceTask.java:44)
at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
{code}
Happens with non-Visor jobs and callables, too!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
Ilya Kasnacheev created IGNITE-7113:
---
Summary: "Key is missing from query" when creating table with
key_type=java.lang.String
Key: IGNITE-7113
URL: https://issues.apache.org/jira/browse/IGNITE-7113
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
When creating a table of
{code}
CREATE TABLE IF NOT EXISTS TableWithStringKey (
ID VARCHAR PRIMARY KEY,
DataNodeId VARCHAR
) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
key_type=java.lang.String, value_type=TableWithStringKey"
{code}
and attempting an insert later
{code}
INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
{code}
There's suddently an exception
{code}
javax.cache.CacheException: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
VALUES ('ref2', 'src2'), params=null]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
at
com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
... 24 more
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
VALUES ('ref2', 'src2'), params=null]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
... 27 more
Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing from
query
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
... 33 more
{code}
that goes away if you remove "key_type=java.lang.String"
I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7080) YARN fails to create containers if Bash functions exported in environment
Ilya Kasnacheev created IGNITE-7080: --- Summary: YARN fails to create containers if Bash functions exported in environment Key: IGNITE-7080 URL: https://issues.apache.org/jira/browse/IGNITE-7080 Project: Ignite Issue Type: Bug Components: yarn Affects Versions: 2.3 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Ignite YARN collects all existing environment variables to pass them to container, including variables with incorrect names, such as Bash functions, which have extra characters at the end, and are ignored by most shells but not the JVM. When you tell Bash to export functions, it puts BASH_FUNC_your_function_name%% variable into env. This is what is causing problems because Ignite YARN picks this variable and tells Hadoop to pass it to container, which leads to incorrectly written startup scrips. Hadoop tries to sanitize env var values but not env var names. I think Ignite should not try to pass all env vars to containers (it may contain sensitive or master-specific vars!). We should only pass env vars that are relevant to containers, such as IGNITE_* vars. See http://apache-ignite-users.70518.x6.nabble.com/Error-running-ignite-in-YARN-td18280.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7043) Incorrect method name suggested when page eviction starts
Ilya Kasnacheev created IGNITE-7043: --- Summary: Incorrect method name suggested when page eviction starts Key: IGNITE-7043 URL: https://issues.apache.org/jira/browse/IGNITE-7043 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.3 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Priority: Trivial Reported via gitter: WARNING: Page evictions started, this will affect storage performance (consider increasing DataStorageConfiguration#setPageCacheSize). since there is no such setting (field/property) setPageCacheSize (ver. 2.3.0#20171028-sha1:8add7fd5) The actual method is DataRegionConfiguration.setMaxSize. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6803) UriDeploymentSpi affects execution of other tasks, including Ignite internals
Ilya Kasnacheev created IGNITE-6803:
---
Summary: UriDeploymentSpi affects execution of other tasks,
including Ignite internals
Key: IGNITE-6803
URL: https://issues.apache.org/jira/browse/IGNITE-6803
Project: Ignite
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Ilya Kasnacheev
>From the maillist:
http://apache-ignite-users.70518.x6.nabble.com/Code-deployment-throught-UriDeploumentSpi-tt17807.html
In our project we need to deploy custom compute tasks into cluster without
cluster restart and p2p class loading.
I try to use org.apache.ignite.spi.deployment.uri.UriDeploumentSpi for that
purpose, but I have a problem.
I have simple Ignite Service and Ignite Compute Task which use it throught
@ServiceResource.
This ComputeTask located into .gar file which was deployed via UriDeploumentSpi.
If I have service implementation on each node(node singleton service) then it
works great.
But if I deploy service as a cluster singleton then task executes correctly
only on node with this service.
On other nodes @ServiceResource returns ServiceProxy that throws exception on
service remote method invokation (lambda with service call cannot be deployed):
{code}
SEVERE: Failed to execute job
[jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86, ses=GridJobSessionImpl
[ses=GridTaskSessionImpl [taskName=task-one, dep=GridDeployment
[ts=1509275650885, depMode=SHARED, clsLdr=GridUriDeploymentClassLoader
[urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
clsLdrId=7eb15d76f51-428ec712-e6d0-4eab-97f9-ce58d7b3e0f5, userVer=0,
loc=true, sampleClsName=com.gridfore.tfedyanin.deploy.Task1,
pendingUndeploy=false, undeployed=false, usage=1],
taskClsName=com.gridfore.tfedyanin.deploy.Task1,
sesId=38a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86,
startTime=1509275650601, endTime=9223372036854775807,
taskNodeId=7919c34c-9a48-4068-bcd6-70dad5595e86,
clsLdr=GridUriDeploymentClassLoader
[urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false,
internal=false, subjId=7919c34c-9a48-4068-bcd6-70dad5595e86,
mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false,
state=INIT, res=null, hash=1254296516]], execName=null],
jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86]]
class org.apache.ignite.IgniteDeploymentException: Failed to auto-deploy task
(was task (re|un)deployed?): class
org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceTopologyCallable
{code}
Problem works as follows:
- Ignite has to determine which node has deployed service, by name.
- Ignite has to send ServiceTopologyCallable task.
- Ignite tries to deploy ServiceTopologyCallable task using UriDeploymentSpi.
- UriDeploymentSpi doesn't have it obviously, but it also tries to fallback
towards "CLASS" loading from local ClassLoader
- Which fails because it is told that ServiceTopologyCallable comes from its
classloader and not from the local one!
So I'm at loss where it should be fixed properly. It is also sad that we are
using all that deploy pipeline to handle IgniteInternal tasks, but there
obviously are non-internal local tasks which might be affected by same problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6775) Divergent descriptions of thread pool sizes in documentation
Ilya Kasnacheev created IGNITE-6775: --- Summary: Divergent descriptions of thread pool sizes in documentation Key: IGNITE-6775 URL: https://issues.apache.org/jira/browse/IGNITE-6775 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: documentation Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Priority: Minor https://apacheignite.readme.io/docs/thread-pools#section-services-pool > The default pool size is max(8, total number of cores) https://apacheignite.readme.io/docs/performance-tips#section-configure-thread-pools > By default, Ignite has it's main thread pool size set to 2 times the > available CPU count What's "main thread pool" also? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6601) Describe walMode on readme.io
Ilya Kasnacheev created IGNITE-6601: --- Summary: Describe walMode on readme.io Key: IGNITE-6601 URL: https://issues.apache.org/jira/browse/IGNITE-6601 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.2 Reporter: Ilya Kasnacheev walMode setting is essential to Persistence performance tuning: default mode is defensive and switching to appropriate walMode easily gives 3x performance boost on real loads. However, walMode is not described on readme.io, and Ignite users has no way of figuring why their persistence performance is unsatisfactory and what compromises they can make to improve it. We should have a section on WAL modes on readme.io on topic of persistence/performance tuning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6590) TCP port in bin/control.sh differs from default
Ilya Kasnacheev created IGNITE-6590:
---
Summary: TCP port in bin/control.sh differs from default
Key: IGNITE-6590
URL: https://issues.apache.org/jira/browse/IGNITE-6590
Project: Ignite
Issue Type: Bug
Components: clients
Affects Versions: 2.2
Reporter: Ilya Kasnacheev
{code}
% bin/ignite.sh -v
>>> Local ports: TCP:8081 TCP:10800 TCP:11211 TCP:47100 TCP:47500
% bin/control.sh --host 127.0.0.1
окт 10, 2017 3:01:26 PM org.apache.ignite.internal.client.impl.GridClientImpl
WARNING: Failed to initialize topology on client start. Will retry in
background.
Caused by: class
org.apache.ignite.internal.client.GridServerUnreachableException: Failed to
connect to any of the servers in list: [/127.0.0.1:11212]
{code}
11212 != 11211. But it's very hard to spot visually. Please fix control.sh to
use correct port by default.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6565) Use long type for size and keySize in cache metrics
Ilya Kasnacheev created IGNITE-6565: --- Summary: Use long type for size and keySize in cache metrics Key: IGNITE-6565 URL: https://issues.apache.org/jira/browse/IGNITE-6565 Project: Ignite Issue Type: Bug Affects Versions: 2.2 Reporter: Ilya Kasnacheev Currently it's int so for large caches there's no way to convey correct value. Should introduce getSizeLong() and getKeySizeLong() Also introduce the same in .Net and make sure that compatibility not broken when passing OP_LOCAL_METRICS and OP_GLOBAL_METRICS. BTW do we need keySize at all? What's it for? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
Ilya Kasnacheev created IGNITE-6564: --- Summary: Incorrect calculation size and keySize for cluster cache metrics Key: IGNITE-6564 URL: https://issues.apache.org/jira/browse/IGNITE-6564 Project: Ignite Issue Type: Bug Affects Versions: 2.2 Reporter: Ilya Kasnacheev Priority: Minor They are currently not passed by ring and therefore only taken from current node, which returns incorrect (local) value. See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6556) setSchema() is case sensitive in the wrong way in Thin JDBC driver
Ilya Kasnacheev created IGNITE-6556:
---
Summary: setSchema() is case sensitive in the wrong way in Thin
JDBC driver
Key: IGNITE-6556
URL: https://issues.apache.org/jira/browse/IGNITE-6556
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.2
Reporter: Ilya Kasnacheev
Suppose we have a cache with
{code}
cacheCfg.setSqlSchema("emp");
{code}
Then, both
{code}
conn.setSchema("emp");
conn.setSqlSchema("\"emp\"");
{code} fail with error "Failed to set schema for DB connection for thread
[schema="emp"]"
And only
{code}
conn.setSchema("EMP");
{code}
works which is confusing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6542) SocketChannel may not be closed in createTcpClient()
Ilya Kasnacheev created IGNITE-6542: --- Summary: SocketChannel may not be closed in createTcpClient() Key: IGNITE-6542 URL: https://issues.apache.org/jira/browse/IGNITE-6542 Project: Ignite Issue Type: Bug Affects Versions: 2.2 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev There's no finally() on ch in TcpCommunicationSpi.createTcpClient() So there's a long block of code where resource consistency is hanging on a hair. This can lead to file descriptor starvation as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6483) Entries count in caches' MX Beans not immediately available
Ilya Kasnacheev created IGNITE-6483:
---
Summary: Entries count in caches' MX Beans not immediately
available
Key: IGNITE-6483
URL: https://issues.apache.org/jira/browse/IGNITE-6483
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1
Reporter: Ilya Kasnacheev
When querying properties like
{code}
cache.mxBean().getOffHeapPrimaryEntriesCount()
{code}
The value is often 0 (zero) initially, even if cache is not empty and located
in offheap.
Local MX Bean returns correct value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6422) In visorcmd "cache on nodes" statistics mixes together primary and backup entries
Ilya Kasnacheev created IGNITE-6422:
---
Summary: In visorcmd "cache on nodes" statistics mixes together
primary and backup entries
Key: IGNITE-6422
URL: https://issues.apache.org/jira/browse/IGNITE-6422
Project: Ignite
Issue Type: Bug
Components: visor
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
Assignee: Vasiliy Sisko
Suppose we have a cache, with 1000 entries, one backup and eviction after 500
entries. Then, off-heap entries are doubled in visorcmd, while on-heap entries
are not:
{code}
+-+
| Name(@) | EmployeesCache(@c0) |
| Nodes | 2 |
| Total size Min/Avg/Max | 1500 / 1500.00 / 1500 |
| Heap size Min/Avg/Max | 500 / 500.00 / 500|
| Off-heap size Min/Avg/Max | 1000 / 1000.00 / 1000 |
+-+
Nodes for: EmployeesCache(@c0)
+=+
| Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
Size | Hi/Mi/Rd/Wr |
+=+
| 37333BC6(@n0), 172.16.9.1 | 8| 4.47 %| 0.40 % | 00:00:47:154 |
Total: 1500 | Hi: 0 |
| | | | | |
Heap: 500 | Mi: 0 |
| | | | | |
Off-Heap: 1000 | Rd: 0 |
| | | | | |
Off-Heap Memory: 0 | Wr: 0 |
+---+--+---+--+--+--+-+
| 26FD4343(@n1), 172.16.9.1 | 8| 3.09 %| 0.23 % | 00:00:41:602 |
Total: 1500 | Hi: 0 |
| | | | | |
Heap: 500 | Mi: 0 |
| | | | | |
Off-Heap: 1000 | Rd: 0 |
| | | | | |
Off-Heap Memory: 0 | Wr: 0 |
+-+
'Hi' - Number of cache hits.
{code}
By contrast, on 1.9 it looks like this:
{code}
Cache 'EmployeesCache(@c0)':
+-+
| Name(@) | EmployeesCache(@c0) |
| Nodes | 2 |
| Total size Min/Avg/Max | 1000 / 1000.00 / 1000 |
| Heap size Min/Avg/Max | 500 / 500.00 / 500|
| Off-heap size Min/Avg/Max | 500 / 500.00 / 500|
+-+
Nodes for: EmployeesCache(@c0)
++
| Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
Size | Hi/Mi/Rd/Wr |
++
| 3229FABE(@n0), 172.16.9.1 | 8| 1.25 %| 0.23 % | 00:00:43:111 |
Total: 1000 | Hi: 0 |
| | | | | |
Heap: 500 | Mi: 0 |
| | | | | |
Off-Heap: 500 | Rd: 0 |
| | | | | |
Off-Heap Memory: 88kb | Wr: 0 |
+---+--+---+--+--+-+-+
| 58FA742B(@n1), 172.16.9.1 | 8| 1.15 %| 0.47 % | 00:00:38:828 |
Total: 1000 | Hi: 0 |
| | | | | |
Heap: 500 | Mi: 0 |
| | | | | |
Off-Heap: 500 | Rd: 0 |
| | | | | |
Off-Heap Memory: 88kb | Wr: 0 |
++
{code}
NB: It might be feasible to keep number of backup entries displayed in
visorcmd, but without adding them up with primary entries. Another dedicated
line perhaps? Should also probably be consistent with other memory kinds.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6238) Fix GridClosureProcessorRemoteTest, add it to suite
Ilya Kasnacheev created IGNITE-6238: --- Summary: Fix GridClosureProcessorRemoteTest, add it to suite Key: IGNITE-6238 URL: https://issues.apache.org/jira/browse/IGNITE-6238 Project: Ignite Issue Type: Improvement Affects Versions: 2.1 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Priority: Trivial It seems that it got lost and suffered from bit rot. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6187) Cache JdbcDatabaseMetadata in JdbcConnection
Ilya Kasnacheev created IGNITE-6187: --- Summary: Cache JdbcDatabaseMetadata in JdbcConnection Key: IGNITE-6187 URL: https://issues.apache.org/jira/browse/IGNITE-6187 Project: Ignite Issue Type: Improvement Components: jdbc Affects Versions: 2.1 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev To avoid re-creating it every time -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6184) No checkClusterState() in IgniteKernal.getOrCreateCaches()
Ilya Kasnacheev created IGNITE-6184: --- Summary: No checkClusterState() in IgniteKernal.getOrCreateCaches() Key: IGNITE-6184 URL: https://issues.apache.org/jira/browse/IGNITE-6184 Project: Ignite Issue Type: Bug Affects Versions: 2.1 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Check if anything else is off, too. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6139) JDBC driver should return actual values for get*Version()
Ilya Kasnacheev created IGNITE-6139: --- Summary: JDBC driver should return actual values for get*Version() Key: IGNITE-6139 URL: https://issues.apache.org/jira/browse/IGNITE-6139 Project: Ignite Issue Type: Improvement Affects Versions: 2.1 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Right now it returns: Database version 1.0 (suggested - actual version from server nodes) JDBC version 1.0 (suggested - 4.1, that's what's in Java 7) Driver version 1.0 (suggested - actual version of running Ignite code) Database product name is "Ignite Cache", probably keep that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6138) JDBC driver metadata queries operate on cache/type instead of schema/table
Ilya Kasnacheev created IGNITE-6138: --- Summary: JDBC driver metadata queries operate on cache/type instead of schema/table Key: IGNITE-6138 URL: https://issues.apache.org/jira/browse/IGNITE-6138 Project: Ignite Issue Type: Bug Components: jdbc Affects Versions: 2.1 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev It has to use toUpperCase() to address the mismatch which isn't a correct approach Some additional information should be passed down from MetadataTask in GridCacheSqlMetadata. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6131) In Visor "cache on nodes" statistics doubles off-heap entries
Ilya Kasnacheev created IGNITE-6131:
---
Summary: In Visor "cache on nodes" statistics doubles off-heap
entries
Key: IGNITE-6131
URL: https://issues.apache.org/jira/browse/IGNITE-6131
Project: Ignite
Issue Type: Bug
Components: visor
Affects Versions: 2.1
Reporter: Ilya Kasnacheev
Assignee: Alexey Kuznetsov
Cache contains 300024 entries actually, but "Nodes for:" shows double that
number under Total field and repeats it in Heap and Off-Heap fields.
{code}
visor> cache -a -c=EmployeesCache
Time of the snapshot: 08/21/17, 17:20:45
+===+
| Name(@) |Mode | Nodes | Entries (Heap / Off-heap)
| Hits| Misses | Reads | Writes |
+===+
| EmployeesCache(@c0) | PARTITIONED | 1 | min: 300024 (0 / 300024)
| min: 0| min: 0| min: 0| min: 0|
| | | | avg: 300024.00 (0.00 / 300024.00)
| avg: 0.00 | avg: 0.00 | avg: 0.00 | avg: 0.00 |
| | | | max: 300024 (0 / 300024)
| max: 0| max: 0| max: 0| max: 0|
+---+
Cache 'EmployeesCache(@c0)':
+---+
| Name(@) | EmployeesCache(@c0) |
| Nodes | 1 |
| Total size Min/Avg/Max | 300024 / 300024.00 / 300024 |
| Heap size Min/Avg/Max | 0 / 0.00 / 0|
| Off-heap size Min/Avg/Max | 300024 / 300024.00 / 300024 |
+---+
Nodes for: EmployeesCache(@c0)
+=+
| Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
Size | Hi/Mi/Rd/Wr |
+=+
| C1AB91DD(@n0), 172.16.9.1 | 8| 25.84 % | 0.17 % | 00:01:09:138 |
Total: 600048| Hi: 0 |
| | | | | |
Heap: 300024 | Mi: 0 |
| | | | | |
Off-Heap: 300024 | Rd: 0 |
| | | | | |
Off-Heap Memory: 0 | Wr: 0 |
+-+
{code}
I'm attaching a simple project (by Ignite console) where this reproduces with
data from https://github.com/datacharmer/test_db
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6125) A range of improvements for JDBC driver metadata queries
Ilya Kasnacheev created IGNITE-6125: --- Summary: A range of improvements for JDBC driver metadata queries Key: IGNITE-6125 URL: https://issues.apache.org/jira/browse/IGNITE-6125 Project: Ignite Issue Type: Improvement Components: clients, jdbc Affects Versions: 2.1 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata is in worrysome state: - Uses cache name instead of schema and type name instead of table. - Makes frivolous use of toUpperCase() to address former. - getPrimaryKeys() never returns anything because of defective use of toUpperCase(). - No tests on indexes, primary keys, schemas or parameters metadata retrieval. - get*Version returns hardcoded obsolete values. - Ignores "catalog" parameter instead of checking if it matches empty catalog. That should be fixes without compromising backwards compatibility too much. Tests may be borrowed from thin client implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat
Ilya Kasnacheev created IGNITE-6070:
---
Summary: Infinite redirects at Spring Security Web Session
Clustering with Tomcat
Key: IGNITE-6070
URL: https://issues.apache.org/jira/browse/IGNITE-6070
Project: Ignite
Issue Type: Bug
Components: websession
Affects Versions: 2.1
Environment: Spring Security, Apache Tomcat
Reporter: Ilya Kasnacheev
Priority: Minor
See
https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error
description.
When Session comes from Ignite but its Authentication is anonymous, Spring
Security does the following check:
{code}
} else if (request.getRequestedSessionId() != null &&
!request.isRequestedSessionIdValid()) {
this.logger.debug("Requested session ID " +
request.getRequestedSessionId() + " is invalid.");
this.invalidSessionStrategy.onInvalidSessionDetected(request, response);
}
{code}
The problem is, in Ignite we never override isRequestedSessionIdValid() in our
request wrappers, so it falls back to Tomcat's own (session) Manager, which
will then find that it has never seen this Session and it is therefore invalid.
Thus failover is triggered, and if there's "invalid-session-url" clause in
Spring Security config, redirect will be issued, possibly circular.
I've attaching a sample Maven WAR project. It should be deployed to two
different Tomcat instances operating on two different ports of same machine,
e.g. 8080 and 8180, and then
http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp should be opened in the
same Web Browser one after another for two ports. The second one should cause
infinite 302 Redirect to same URL.
There's also a minor bug in the same code: see session.jsp in the example. It
will needlessly throw NPE in WebSessionFilter:1001 and confuse web server.
Should output "OK" when fixed.
Discussion:
By the way, letting the web server to get hold on Sessions that it creates for
us causes additional problems: it's going to store these sessions in parallel
with Ignite, consuming memory in the process that first saw a given session. We
should probably have (possibly a third party) an Ignite-using Manager
implementation for Tomcat specifically. It will be much simpler than
filter-based approach while performing better.
Or maybe we should create our own Sessions that we never allow the web server
to see.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
