[jira] [Created] (IGNITE-19554) [ducktests] Allow to configure more options in communication and data storage
Sergey Korotkov created IGNITE-19554: Summary: [ducktests] Allow to configure more options in communication and data storage Key: IGNITE-19554 URL: https://issues.apache.org/jira/browse/IGNITE-19554 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov Assignee: Sergey Korotkov Ducktests need more options to be configurable _Data storage_ / _Data region_ * lazy_memory_allocation * page_size * wal_page_compression * wal_page_compression_level * wal_path * wal_archive_path _TcpCommunicationSpi_ * unacknowledged_messages_buffer_size -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19520) Add verification of unit uploading
[ https://issues.apache.org/jira/browse/IGNITE-19520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19520: Labels: iep-103 ignite-3 (was: ignite-3) > Add verification of unit uploading > -- > > Key: IGNITE-19520 > URL: https://issues.apache.org/jira/browse/IGNITE-19520 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > h3. Node restart during unit deployment process > If a target node was restarted during uploading process then the node must > find all deployment units with nodeDURecord.status == UPLOADING for restarted > node and if clusterDURecord.status == DEPLOYED all such deployment unit > should be removed from the node. Corresponding statuses also must be removed > from meta storage for this node. Deployment units could be requested again if > needed and deployment on-demand will be initiated for this case. > > Note, if the target node is in majority then the process which coordinates > deployment process should ensure that either another node from majority will > be chosen as target or restarted node will repeat the process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19519) Add remove verification after restart
[ https://issues.apache.org/jira/browse/IGNITE-19519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19519: Labels: iep-103 ignite-3 (was: ignite-3) > Add remove verification after restart > -- > > Key: IGNITE-19519 > URL: https://issues.apache.org/jira/browse/IGNITE-19519 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > h3. Node restart during unit removal process > If a target node was restarted during deployment unit removal process then > the node must find all deployment units with clusterDURecord.status == > OBSOLETE or clusterDURecord.status == REMOVING for restarted node and finish > deployment unit removal process as described in the previous section. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19521) Rework units list command
[ https://issues.apache.org/jira/browse/IGNITE-19521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19521: Labels: iep-103 ignite-3 (was: ignite-3) > Rework units list command > -- > > Key: IGNITE-19521 > URL: https://issues.apache.org/jira/browse/IGNITE-19521 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Vadim Pakhnushev >Priority: Major > Labels: iep-103, ignite-3 > > h3. List of units on the cluster or on the node > Prints out a list of all deployment units or of given deployment unit with > identifier on the cluster or node and their status. > > $ ignite3 unit list [] [--version > ]] [--node ] [--status [UPLOADING[, > DEPLOYED [, … > > Output example: > > | Unit | Version | Status | > | foo.example.job | 1.0.0 | DEPLOYED | > | foo.example.job | 1.0.1 | DEPLOYED | > | foo.example.job | 1.0.2 | UPLOADING | > | foo.example.task | 1.0.0 | DEPLOYED | > > Options: > * --version - filters out deployment unit by version (exact match assumed). > * --node - defines target node. > --status - allows to filter out deployment units by given statuses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19522) Modify deploy unit command
[ https://issues.apache.org/jira/browse/IGNITE-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19522: Labels: iep-103 ignite-3 (was: ignite-3) > Modify deploy unit command > --- > > Key: IGNITE-19522 > URL: https://issues.apache.org/jira/browse/IGNITE-19522 > Project: Ignite > Issue Type: New Feature > Components: cli, rest >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > ignite3 unit deploy --version (-uv) > --path (-up) | [--nodes > MAJORITY|ALL|] > > Options: > * --version -uv - defines the deployment unit’s version > (). > * --path -up - path to JAR-file () or to the directory () which > contains all required class files and resources. > * --nodes - defines the set of target nodes where the deployment unit will > be deployed. The possible options are possible: > * MAJORITY - Default value. The CMG majority nodes will be chosen as the > target nodes (including the leader node). > * ALL - All available nodes will be chosen as the target nodes. In this case > “available” means The CMG majority nodes (see MAJORITY option) and all nodes > that will be live during the deployment process. If some node will go offline > (excluding the CMG majority nodes) then this node will not finish the > deployment process and will request deployment on-demand. > * - All nodes with corresponding consistent IDs in form node_id2, …]>. Note, that these nodes are treated as an addition to the CMG > majority nodes and behavior is similar to the ALL option (the deployment unit > will be deployed only on available nodes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19476) Implement unit deploy on demand API
[ https://issues.apache.org/jira/browse/IGNITE-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19476: Labels: iep-103 ignite-3 (was: ignite-3) > Implement unit deploy on demand API > --- > > Key: IGNITE-19476 > URL: https://issues.apache.org/jira/browse/IGNITE-19476 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > If code execution is initiated on some node (due to a Compute API invocation) > and this target node doesn’t have a required deployment unit it could be > requested from some node which already has the required deployment unit. It > means that the required deployment unit has clusterDURecord.status == > DEPLOYED and there is at least one node where nodeDURecord.status == > DEPLOYED. If this conditions are met the following steps must be performed: > > # Add meta storage record for target node and deployment unit where > nodeDURecord.status == UPLOADING and nodeDURecord.depOpId == > clusterDUStatus.depOpId. The node should prevent concurrent races between > different threads. It’s achievable without any meta storage operations > because there is no other node which can initiate the on-demand deployment > process.. > Note that if clusterDURecord.status == DEPLOYED && nodeDURecord.status == > UPLOADING => deployment on-demand is in progress for a given deployment unit > and given node. > As soon as the deployment unit is uploaded to the target node, > nodeDURecord.status must be changed to DEPLOYED value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19515) Add using deployment units to compute job definition
[ https://issues.apache.org/jira/browse/IGNITE-19515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19515: Labels: iep-103 ignite-3 (was: ignite-3) > Add using deployment units to compute job definition > > > Key: IGNITE-19515 > URL: https://issues.apache.org/jira/browse/IGNITE-19515 > Project: Ignite > Issue Type: New Feature > Components: compute >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > h4. IgniteCompute interface > # All methods execute, executeColocated and broadcast which receive type > Class as parameter must be removed because it is impossible to get Class > instance for the task from class loader which is not bootstrap, system or > extension. Instead methods which get task class as String must be used. > # All methods execute, executeColocated and broadcast must get > DeploymentUnit’s array as parameter in order to define execution context > (dependencies and order of class loading). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19448) Add checksums for deployment unit content
[ https://issues.apache.org/jira/browse/IGNITE-19448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19448: Labels: iep-103 ignite-3 (was: ignite-3) > Add checksums for deployment unit content > - > > Key: IGNITE-19448 > URL: https://issues.apache.org/jira/browse/IGNITE-19448 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19301) Add --all flag to undeploy command
[ https://issues.apache.org/jira/browse/IGNITE-19301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19301: Labels: iep-103 ignite-3 (was: ignite-3) > Add --all flag to undeploy command > -- > > Key: IGNITE-19301 > URL: https://issues.apache.org/jira/browse/IGNITE-19301 > Project: Ignite > Issue Type: New Feature > Components: cli >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > Intorduce --all flag to undeploy command which mutually exclusive to > --version. This flag should undeploy all version of provided unit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19076) Add support of deployment statuses to CLI
[ https://issues.apache.org/jira/browse/IGNITE-19076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19076: Labels: iep-103 ignite-3 (was: ignite-3) > Add support of deployment statuses to CLI > - > > Key: IGNITE-19076 > URL: https://issues.apache.org/jira/browse/IGNITE-19076 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > In IGNITE-18973 introduced deployment unit statuses. Need to add statutes > support to CLI and REST -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19385) Unit id should satisfy maven convension
[ https://issues.apache.org/jira/browse/IGNITE-19385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19385: Labels: iep-103 ignite-3 (was: ignite-3) > Unit id should satisfy maven convension > --- > > Key: IGNITE-19385 > URL: https://issues.apache.org/jira/browse/IGNITE-19385 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > Deploy unit identifier should required > ([https://maven.apache.org/guides/mini/guide-naming-conventions.html]). > > Need to add verification of unit id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19025) Remove deployment related code from API module
[ https://issues.apache.org/jira/browse/IGNITE-19025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19025: Labels: iep-103 ignite-3 (was: ignite-3) > Remove deployment related code from API module > -- > > Key: IGNITE-19025 > URL: https://issues.apache.org/jira/browse/IGNITE-19025 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Deployment code functionality shouldn't be exposed to public API module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19449) Introduce node to deploy argument
[ https://issues.apache.org/jira/browse/IGNITE-19449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19449: Labels: iep-103 ignite-3 (was: ignite-3) > Introduce node to deploy argument > - > > Key: IGNITE-19449 > URL: https://issues.apache.org/jira/browse/IGNITE-19449 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19021) Support the directory deployment
[ https://issues.apache.org/jira/browse/IGNITE-19021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19021: Labels: iep-103 ignite-3 (was: ignite-3) > Support the directory deployment > > > Key: IGNITE-19021 > URL: https://issues.apache.org/jira/browse/IGNITE-19021 > Project: Ignite > Issue Type: Improvement > Components: cli, rest >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > Now it is impossible to deploy the directory. The case: deploy several jars > or just a directory with class files. > The solution might be: > - zip the dir on the client side > - deploy the zip > - unzip on the server side -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19475) Implement class loaders hierarchy
[ https://issues.apache.org/jira/browse/IGNITE-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19475: Labels: iep-103 ignite-3 (was: ignite-3) > Implement class loaders hierarchy > - > > Key: IGNITE-19475 > URL: https://issues.apache.org/jira/browse/IGNITE-19475 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Ivan Gagarkin >Priority: Major > Labels: iep-103, ignite-3 > Attachments: image-2023-05-15-14-09-41-734.png > > > h3. Class loaders hierarchy > !image-2023-05-15-14-09-41-734.png! > > For user defined classes loading and execution are responsible class loaders. > The class loaders are built in the hierarchy pictured above. > > The Bootstrap, the extension and the system class loaders are provided by the > runtime environment and each class loader first delegates class loading logic > to the parent class loader. > > Such an approach is not suitable for all user use cases. For example it is > impossible to override behavior of some classes. Apache Ignite 3 provides > more flexible behavior of class loaders which could be managed by a user - > Ignite chained class loader. In general, the Ignite class loader behave like > web application classloader in popular web application containers (e.g. > Apache Tomcat): > > * Ignite class loader disallows to override classes from the following > packages: > * org.java.* > * org.javax.* > * org.apache.ignite.* > If the system tries to find a class from packages listed above then the > Ignite class loader should delegate this logic to the parent class loader > first (in our hierarchy it is the system class loader). > * Ignite class loader allows to override any non-system and non-Ignite > class. If the system tries to find class from any package that is not listed > in the previous item then Ignite class loader should try to find class over > corresponding deployment unit and delegate this logic to the parent class > loader in case of failure. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19516) Add latest semantic version of unit to execution
[ https://issues.apache.org/jira/browse/IGNITE-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19516: Labels: iep-103 ignite-3 (was: ignite-3) > Add latest semantic version of unit to execution > > > Key: IGNITE-19516 > URL: https://issues.apache.org/jira/browse/IGNITE-19516 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > h4. LATEST semantics > The only difference between regular behavior and LATEST semantics is the need > to resolve the latest version of an available deployment unit before every > code execution. It means that two consecutive calls of the same task/job > could lead to creation of different class loaders because a new version of > the deployment unit can be deployed between these calls. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19517) Add class resolution mechinism to compute
[ https://issues.apache.org/jira/browse/IGNITE-19517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19517: Labels: iep-103 ignite-3 (was: ignite-3) > Add class resolution mechinism to compute > - > > Key: IGNITE-19517 > URL: https://issues.apache.org/jira/browse/IGNITE-19517 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > h4. Regular behavior > As soon as code execution is initiated due to invocation one of the methods > execute, executeColocated or broadcast the following steps must be performed: > > # Get a class loader which is identified by an array of DeploymentUnit > instances passed to the called method. > # If the class loader doesn’t exist yet, then create it: > # For each deployment unit check that it is deployed: > # If the deployment unit is deployed and can be used for code execution then > use its location for class loading > # If the deployment unit is deployed to the cluster but is not deployed to > the node then initiate deployment on-demand. > # If the deployment unit doesn’t exist, throw ClassNotFoundException with > _“. Deployment unit doesn’t exist”_ > message, where __ is a concatenation of ID and > version (e.g. com.example:1.0.0) > # Check that deployment unit can be used for code execution: > # If the deployment unit exists but can’t be used for code execution, throw > ClassNotFoundException with _“. Deployment unit > can’t be used: [clusterStatus = > , nodeStatus = ]”_ message. > # Load a class of task/job passed to the Compute API method as parameter. At > this point ClassNotFoundException could be thrown from the class loader. > # Execute required code. > In order to have the possibility to detect that some code is in progress and > uses some class loader a reference counter could be used. The counter must be > incremented when job execution is started and decremented when code execution > is finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19518) Add unit validation after node restart
[ https://issues.apache.org/jira/browse/IGNITE-19518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19518: Labels: iep-103 ignite-3 (was: ignite-3) > Add unit validation after node restart > -- > > Key: IGNITE-19518 > URL: https://issues.apache.org/jira/browse/IGNITE-19518 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > h3. Validation after node restart > Every deployment unit with nodeDURecord.status == DEPLOYED must be validated > in order to prevent a situation when the deployment unit was undeployed and > then deployed again with the same deployment unit ID and version but with > different content (some kind of [ABA > problem|https://en.wikipedia.org/wiki/ABA_problem]). The nodeDURecord.depOpId > and corresponding clusterDURecord.depOpId must be the same. Otherwise the > deployment unit should be removed from the node. > > For every nodeDURecord(depOpId, UPLOADING) record corresponding > clusterDURecord(depOpId, DEPLOYED) or clusterDURecord(depOpId, UPLOADING) > must exist. Otherwise the invalid deployment unit must be removed from the > node. > > For every nodeDURecord(depOpId, DEPLOYED) record corresponding > clusterDURecord(depOpId, DEPLOYED) or clusterDURecord(depOpId, UPLOADING) > must exist. Otherwise the invalid deployment unit must be removed from the > node. > For every nodeDURecord(depOpId, OBSOLETE) or nodeDURecord(depOpId, REMOVING) > record corresponding clusterDURecord(depOpId, OBSOLETE) or > clusterDURecord(depOpId, REMOVING) must exist. Otherwise the invalid > deployment unit must be removed from the node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19450) Add * char to latest version of unit in list command
[ https://issues.apache.org/jira/browse/IGNITE-19450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19450: Labels: iep-103 ignite-3 (was: ignite-3) > Add * char to latest version of unit in list command > > > Key: IGNITE-19450 > URL: https://issues.apache.org/jira/browse/IGNITE-19450 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19107) Remove deploy with LATEST version
[ https://issues.apache.org/jira/browse/IGNITE-19107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19107: Labels: iep-103 ignite-3 (was: ignite-3) > Remove deploy with LATEST version > - > > Key: IGNITE-19107 > URL: https://issues.apache.org/jira/browse/IGNITE-19107 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19024) Atomic redeploy support
[ https://issues.apache.org/jira/browse/IGNITE-19024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19024: Labels: iep-103 ignite-3 (was: ignite-3) > Atomic redeploy support > --- > > Key: IGNITE-19024 > URL: https://issues.apache.org/jira/browse/IGNITE-19024 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently, its impossibl;e to deploy unit with id and version which already > exist. In this case before deploy this unit should be undeployed firstly, but > this is not atomic operation. > Need to introduce `force` marker in deploy method. If force enable existed > unit should be undeployed and new one deployed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19384) Rework units metastorage layer
[
https://issues.apache.org/jira/browse/IGNITE-19384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-19384:
Labels: iep-103 ignite-3 (was: ignite-3)
> Rework units metastorage layer
> --
>
> Key: IGNITE-19384
> URL: https://issues.apache.org/jira/browse/IGNITE-19384
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: iep-103, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently deployment units stored in metastorage like one entity per unit
> with key structure
> *deploy-unit.units.\{id}:\{version}* and value
> *\{id}:\{value}:\{status}:\{fileNames}:\{nodeConsistentIds}* where each part
> encoded to Base64.
> Need to rework it. The following steps must be performed during the uploading
> process:
> # Choose a majority which contains available nodes including a leader.
> # Create meta storage record for given deployment unit clusterDUStatus ==
> UPLOADING.
> # Initiate uploading of files to the target nodes and create meta storage
> record for given deployment unit and node nodeDUStatus == UPLOADING.
> # As soon as the deployment unit is uploaded to the node, nodeDUStatus must
> be changed to DEPLOYED value.
> # As soon as the deployment unit is uploaded to the target nodes,
> clusterDUStatus must be changed to DEPLOYED value.
>
> A deployment unit is considered deployed to the cluster only if
> clusterDUStatus == DEPLOYED. It means that there is at least one available
> node which can be a source for downloading the deployment unit on demand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18973) Introduce units status
[ https://issues.apache.org/jira/browse/IGNITE-18973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18973: Labels: iep-103 ignite-3 (was: ignite-3) > Introduce units status > -- > > Key: IGNITE-18973 > URL: https://issues.apache.org/jira/browse/IGNITE-18973 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The status defines a state of deployment unit in the cluster. The following > statuses are allowed: > UPLOADING - unit deployment is in progress. > DEPLOYED - unit is deployed on the cluster. > OBSOLETE - remove command was initiated for the unit and it will be removed > soon. > REMOVING - unit removal from the cluster is in progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18941) .NET: Thin 3.0: Implement IgniteDeployment APIs
[ https://issues.apache.org/jira/browse/IGNITE-18941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18941: Labels: iep-103 ignite-3 (was: ignite-3) > .NET: Thin 3.0: Implement IgniteDeployment APIs > --- > > Key: IGNITE-18941 > URL: https://issues.apache.org/jira/browse/IGNITE-18941 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-103, ignite-3 > > Implement IgniteDeployment APIs in .NET client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18870) Provide deployment units by node consistent id
[ https://issues.apache.org/jira/browse/IGNITE-18870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18870: Labels: iep-103 ignite-3 (was: ignite-3) > Provide deployment units by node consistent id > -- > > Key: IGNITE-18870 > URL: https://issues.apache.org/jira/browse/IGNITE-18870 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Need to extend interface of deployment unit api from IGNITE-18729 and add > possibility to find units by node constent id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19009) Introduce file transfer support in messaging
[ https://issues.apache.org/jira/browse/IGNITE-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-19009: Labels: iep-103 ignite-3 (was: ignite-3) > Introduce file transfer support in messaging > > > Key: IGNITE-19009 > URL: https://issues.apache.org/jira/browse/IGNITE-19009 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > > Current implemenatation of Network force to load deployment unit content to > heap as byte[]. This is a potential easy way of OOM. > > As solution we need to introduce lazy buffer in Network code where file will > readed by chunks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18730) Rest API for deployment units
[ https://issues.apache.org/jira/browse/IGNITE-18730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18730: Labels: iep-103 ignite-3 (was: ignite-3) > Rest API for deployment units > - > > Key: IGNITE-18730 > URL: https://issues.apache.org/jira/browse/IGNITE-18730 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h > Remaining Estimate: 0h > > Implement REST API for Deployment unit API inroduced in IGNITE-18729. > REST API should duplicate public API of deployment and have follow endpoints > # Deploy unit > # Undeploy unit > # Get all units > # Get all version of unit by id > # Get status of unit by id and version -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18940) Java thin 3.0: Implement IgniteDeployment APIs
[ https://issues.apache.org/jira/browse/IGNITE-18940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18940: Labels: iep-103 ignite-3 (was: ignite-3) > Java thin 3.0: Implement IgniteDeployment APIs > -- > > Key: IGNITE-18940 > URL: https://issues.apache.org/jira/browse/IGNITE-18940 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-103, ignite-3 > > Implement *IgniteDeployment* interface in Java client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18731) CLI command for deployment units
[ https://issues.apache.org/jira/browse/IGNITE-18731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18731: Labels: iep-103 ignite-3 (was: ignite-3) > CLI command for deployment units > > > Key: IGNITE-18731 > URL: https://issues.apache.org/jira/browse/IGNITE-18731 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18729) Ignite deployment manager
[ https://issues.apache.org/jira/browse/IGNITE-18729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18729: Labels: iep-103 ignite-3 (was: ignite-3) > Ignite deployment manager > - > > Key: IGNITE-18729 > URL: https://issues.apache.org/jira/browse/IGNITE-18729 > Project: Ignite > Issue Type: New Feature >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 9h > Remaining Estimate: 0h > > 1. Accept deployment unit. > 2. Store unit on CMG. > 3. Store unit metainformation (Sys table, metastorage?). > 4. Undeploy unit. > 5. Return list of deployed unit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16948) Support multiple connection between two nodes and paired connections
[ https://issues.apache.org/jira/browse/IGNITE-16948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-16948: Labels: iep-103 ignite-3 (was: ignite-3) > Support multiple connection between two nodes and paired connections > > > Key: IGNITE-16948 > URL: https://issues.apache.org/jira/browse/IGNITE-16948 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Semyon Danilov >Assignee: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > To increase throughput and reduce latency we might need to use different > connections for different modules of ignite. For example, one connection for > scalecube and another for raft. > Also, it might be useful to create paired connections so every two nodes have > two connections and not one -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18728) Code deployment for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-18728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-18728: Labels: iep-103 ignite-3 (was: ignite-3) > Code deployment for Ignite 3 > > > Key: IGNITE-18728 > URL: https://issues.apache.org/jira/browse/IGNITE-18728 > Project: Ignite > Issue Type: Epic >Reporter: Mikhail Pochatkin >Priority: Major > Labels: iep-103, ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19553) Metrics for operations on indexes
Aleksey Plekhanov created IGNITE-19553:
--
Summary: Metrics for operations on indexes
Key: IGNITE-19553
URL: https://issues.apache.org/jira/browse/IGNITE-19553
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currently, we don't have metrics about performance of operations on indexes. We
have, {{io.statistics.sortedIndexes.*}} metrics about logical and physical page
reads, but without operation types and without duration. It will be heplful to
have metrics for different operations on indexes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19552) ArrayStoreException on connect to remote server node
[
https://issues.apache.org/jira/browse/IGNITE-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-19552:
-
Assignee: Konstantin Orlov
> ArrayStoreException on connect to remote server node
>
>
> Key: IGNITE-19552
> URL: https://issues.apache.org/jira/browse/IGNITE-19552
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Konstantin Orlov
>Priority: Major
>
> The problem consistently reproduces with the remote server node, sometimes -
> with local one.
> 1) Start single server node
> 2) Active cluster
> 3) Connect to the cluster via JDBC driver.
> Expected result: connection established
> Actual result:
> {code:java}
> [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS
> usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR,
> field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6
> VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46
> PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to
> initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 -
> R:/127.0.0.1:53528]java.lang.ArrayStoreException:
> org.apache.ignite.internal.client.proto.ClientMessageDecoderat
> org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250)
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
>at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
> Important - use one of the last builds.
> TBD: environment details and particular commit with the bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19552) ArrayStoreException on connect to remote server node
[
https://issues.apache.org/jira/browse/IGNITE-19552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-19552:
--
Labels: ignite-3 (was: )
> ArrayStoreException on connect to remote server node
>
>
> Key: IGNITE-19552
> URL: https://issues.apache.org/jira/browse/IGNITE-19552
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> The problem consistently reproduces with the remote server node, sometimes -
> with local one.
> 1) Start single server node
> 2) Active cluster
> 3) Connect to the cluster via JDBC driver.
> Expected result: connection established
> Actual result:
> {code:java}
> [16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS
> usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR,
> field2 VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6
> VARCHAR, field7 VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46
> PM io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to
> initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 -
> R:/127.0.0.1:53528]java.lang.ArrayStoreException:
> org.apache.ignite.internal.client.proto.ClientMessageDecoderat
> org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250)
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
>at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
> at
> io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829) {code}
> Important - use one of the last builds.
> TBD: environment details and particular commit with the bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19533) Rename UNKNOWN_ERR error code to INTERNAL_ERR
[ https://issues.apache.org/jira/browse/IGNITE-19533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19533: - Description: The UNKNOWN_ERR error code should be renamed to INTERNAL_ERR. The @Deprecated should be removed as well. The INTRNAL_ERR error code should be considered as the product's internal error caused by faulty logic or coding in the product. In general, this error code represents a non-recoverable error that should be provided to code maintainers. It seems to me the UNEXPECTED_ERR error code just duplicates `INTERNAL_ERR` one, so, it should be removed. was: The UNKNOWN_ERR error code should be renamed to INTRNAL_ERR. The @Deprecated should be removed as well. The INTRNAL_ERR error code should be considered as the product's internal error caused by faulty logic or coding in the product. In general, this error code represents a non-recoverable error that should be provided to code maintainers. It seems to me the UNEXPECTED_ERR error code just duplicates `INTERNAL_ERR` one, so, it should be removed. > Rename UNKNOWN_ERR error code to INTERNAL_ERR > - > > Key: IGNITE-19533 > URL: https://issues.apache.org/jira/browse/IGNITE-19533 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: iep-84, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The UNKNOWN_ERR error code should be renamed to INTERNAL_ERR. The @Deprecated > should be removed as well. > The INTRNAL_ERR error code should be considered as the product's internal > error caused by faulty logic or coding in the product. In general, this error > code represents a non-recoverable error that should be provided to code > maintainers. > It seems to me the UNEXPECTED_ERR error code just duplicates `INTERNAL_ERR` > one, so, it should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19552) ArrayStoreException on connect to remote server node
Alexander Belyak created IGNITE-19552:
-
Summary: ArrayStoreException on connect to remote server node
Key: IGNITE-19552
URL: https://issues.apache.org/jira/browse/IGNITE-19552
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 3.0
Reporter: Alexander Belyak
The problem consistently reproduces with the remote server node, sometimes -
with local one.
1) Start single server node
2) Active cluster
3) Connect to the cluster via JDBC driver.
Expected result: connection established
Actual result:
{code:java}
[16:08:46][INFO ][Thread-2] Create table request: CREATE TABLE IF NOT EXISTS
usertable (yscb_key VARCHAR PRIMARY KEY, field0 VARCHAR, field1 VARCHAR, field2
VARCHAR, field3 VARCHAR, field4 VARCHAR, field5 VARCHAR, field6 VARCHAR, field7
VARCHAR, field8 VARCHAR, field9 VARCHAR);May 23, 2023 4:08:46 PM
io.netty.channel.ChannelInitializer exceptionCaughtWARNING: Failed to
initialize a channel. Closing: [id: 0x0392f8b4, L:/127.0.0.1:10800 -
R:/127.0.0.1:53528]java.lang.ArrayStoreException:
org.apache.ignite.internal.client.proto.ClientMessageDecoderat
org.apache.ignite.client.handler.ClientHandlerModule$1.initChannel(ClientHandlerModule.java:250)
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:1114)
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
at
io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
at
io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
at
io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
at
io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
at
io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829) {code}
Important - use one of the last builds.
TBD: environment details and particular commit with the bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19551) .NET: Thin 3.0: Enable SourceLink
[ https://issues.apache.org/jira/browse/IGNITE-19551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19551: Description: Enable SourceLink to improve debugging experience for the users: https://github.com/dotnet/sourcelink/blob/main/README.md Use nuget.info to verify the result. Currently, it is not fully enabled: https://nuget.info/packages/Apache.Ignite/3.0.0-beta1 was: Enable SourceLink to improve debugging experience for the users: https://github.com/dotnet/sourcelink/blob/main/README.md > .NET: Thin 3.0: Enable SourceLink > - > > Key: IGNITE-19551 > URL: https://issues.apache.org/jira/browse/IGNITE-19551 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Enable SourceLink to improve debugging experience for the users: > https://github.com/dotnet/sourcelink/blob/main/README.md > Use nuget.info to verify the result. Currently, it is not fully enabled: > https://nuget.info/packages/Apache.Ignite/3.0.0-beta1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19551) .NET: Thin 3.0: Enable SourceLink
Pavel Tupitsyn created IGNITE-19551: --- Summary: .NET: Thin 3.0: Enable SourceLink Key: IGNITE-19551 URL: https://issues.apache.org/jira/browse/IGNITE-19551 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Enable SourceLink to improve debugging experience for the users: https://github.com/dotnet/sourcelink/blob/main/README.md -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19505) Design distribution zone based partition replication
[ https://issues.apache.org/jira/browse/IGNITE-19505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19505: - Labels: ignite-3 (was: ) > Design distribution zone based partition replication > > > Key: IGNITE-19505 > URL: https://issues.apache.org/jira/browse/IGNITE-19505 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > The current data layout is builded around the table partitions. Each table > partition forms the group of replicas with the RAFT protocol (pluggable > protocol in future). This layout was great up to the moment, when we decided > to introduce the support of collocation for any chosen group of tables. > After some rounds of discussions we decided to use the distribution zone as > the scope of collocation. So, the partition will be managed by the > distribution zone associated entity, instead of the table one. > *Definition of done* > Under this issue we need to provide the design document, which will describe > the process for migration the current state to the: > - Table partitions must be the part (one-to-one relation) of the zone > partition. > - The data layout for partitions of different tables inside the one zone > partition - must be described as well. > - Tables, which share the one distribution zone will be collocated (the same > key must be stored in the same distribution zone partition) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19508) Design and breakdown tx on unstable topology topic.
[ https://issues.apache.org/jira/browse/IGNITE-19508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19508: - Labels: ignite-3 (was: ) > Design and breakdown tx on unstable topology topic. > --- > > Key: IGNITE-19508 > URL: https://issues.apache.org/jira/browse/IGNITE-19508 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > h3. Motivation > General approach of tx recovery/tx on unstable topology is available in > described in > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Recovery|IEP-91] > Thus it's required to prepare full set of tickets in order to handle > * Data node (primaryReplica|majority) failure. > * Commit partition failure. > * Tx coordinator failure. > except disaster recovery and graceful primary replica switch, that will be > covered in separate topics. > h3. Definition of Done > * Corresponding epic is created. > * Epic is populated with full set of tasks. > * Tasks are estimated and assigned to sprints. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19550) Reuse IDs of dropped Catalog objects for new objects
Roman Puchkovskiy created IGNITE-19550: -- Summary: Reuse IDs of dropped Catalog objects for new objects Key: IGNITE-19550 URL: https://issues.apache.org/jira/browse/IGNITE-19550 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 In IGNITE-19524, we are switching from UUIDs to ints as IDs of the Catalog objects (tables, indices, views, zones). Some users have use-cases where they constantly create, drop and recreate same tables. In such cases, it might make sense to reuse object IDs to slow down the growth of the global counter. A design is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19549) Handle wrap-around of Catalog object IDs
Roman Puchkovskiy created IGNITE-19549: -- Summary: Handle wrap-around of Catalog object IDs Key: IGNITE-19549 URL: https://issues.apache.org/jira/browse/IGNITE-19549 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 We are planning to switch from UUIDs to ints as Catalog object (tables, indices, zones, views) IDs (IGNITE-19524). int allows 2/4 billion of values (approx); if we add columns to the category of objects that need these IDs, it seems theoretically possible to get into wrap-around situation. Design of some mechanism might be needed. (Although, in practice, it seems that WA cannot happen). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19531) Switch table IDs from UUIDs to integers
[ https://issues.apache.org/jira/browse/IGNITE-19531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-19531: --- Description: Currently, as tables are stored as named list items in the Configuration, they are internally (to the configuration) identified by UUIDs. The same UUIDs are also used to identify tables in the whole system. We need to change the latter: that is, in addition to the internal IDs (needed only for configuration), we need to generate integer IDs and use them in the rest of the system to identify tables. For now, table IDs should be generated using same global counter that will be used to generate index and zone IDs. Internal IDs will remain until we switch from storing tables/indices/zones in the Configuration to storing them in the Catalog (this is out of scope of this task). > Switch table IDs from UUIDs to integers > --- > > Key: IGNITE-19531 > URL: https://issues.apache.org/jira/browse/IGNITE-19531 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, as tables are stored as named list items in the Configuration, > they are internally (to the configuration) identified by UUIDs. The same > UUIDs are also used to identify tables in the whole system. > We need to change the latter: that is, in addition to the internal IDs > (needed only for configuration), we need to generate integer IDs and use them > in the rest of the system to identify tables. > For now, table IDs should be generated using same global counter that will be > used to generate index and zone IDs. > Internal IDs will remain until we switch from storing tables/indices/zones in > the Configuration to storing them in the Catalog (this is out of scope of > this task). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18979) Add snapshot creation time in SnapshotView
[ https://issues.apache.org/jira/browse/IGNITE-18979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18979: Description: Currently SnapshotView doesn't show snapshot creation time. Currently this value can be extracted from metrics (snapshot.endTime), but: # it shows only on the snapshot initiator node # this value is not persisted # it is overrided after new snapshot created. was: Currently SnapshotView doesn't show snapshot creation time. Currently this value can be extracted from metrics (snapshot.endTime), but: # it shows only on the snapshot initiator node # this value is not persisted # it is overrided after new snapshot created. >From other hand it's useful get info about when full/incremental snapshot was >created. > Add snapshot creation time in SnapshotView > -- > > Key: IGNITE-18979 > URL: https://issues.apache.org/jira/browse/IGNITE-18979 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > > Currently SnapshotView doesn't show snapshot creation time. Currently this > value can be extracted from metrics (snapshot.endTime), but: > # it shows only on the snapshot initiator node > # this value is not persisted > # it is overrided after new snapshot created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19547) Switch index IDs from UUID to int
[ https://issues.apache.org/jira/browse/IGNITE-19547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-19547: --- Description: Currently, as indices are stored as named list items in the Configuration, they are internally (to the configuration) identified by UUIDs. The same UUIDs are also used to identify indices in the whole system. We need to change the latter: that is, in addition to the internal IDs (needed only for configuration), we need to generate integer IDs and use them in the rest of the system to identify indices. For now, index IDs should be generated using same global counter that will be used to generate table and zone IDs. Internal IDs will remain until we switch from storing tables/indices/zones in the Configuration to storing them in the Catalog (this is out of scope of this task). was: Currently, as indices are stored as named list items in the Configuration, they are internally (to the configuration) identified by UUIDs. The same UUIDs are also used to identify indices in the whole system. We need to change the latter: that is, in addition to the internal IDs (needed only for configuration), we need to generate integer IDs and use them in the rest of the system to identify indices. Internal IDs will remain until we switch from storing tables/indices/zones in the Configuration to storing them in the Catalog (this is out of scope of this task). > Switch index IDs from UUID to int > - > > Key: IGNITE-19547 > URL: https://issues.apache.org/jira/browse/IGNITE-19547 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, as indices are stored as named list items in the Configuration, > they are internally (to the configuration) identified by UUIDs. The same > UUIDs are also used to identify indices in the whole system. > We need to change the latter: that is, in addition to the internal IDs > (needed only for configuration), we need to generate integer IDs and use them > in the rest of the system to identify indices. > For now, index IDs should be generated using same global counter that will be > used to generate table and zone IDs. > Internal IDs will remain until we switch from storing tables/indices/zones in > the Configuration to storing them in the Catalog (this is out of scope of > this task). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19548) Switch distribution zone IDs from UUID to int
Roman Puchkovskiy created IGNITE-19548: -- Summary: Switch distribution zone IDs from UUID to int Key: IGNITE-19548 URL: https://issues.apache.org/jira/browse/IGNITE-19548 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 Currently, as zones are stored as named list items in the Configuration, they are internally (to the configuration) identified by UUIDs. The same UUIDs are also used to identify zones in the whole system. We need to change the latter: that is, in addition to the internal IDs (needed only for configuration), we need to generate integer IDs and use them in the rest of the system to identify zones. For now, zone IDs should be generated using same global counter that will be used to generate table and index IDs. Internal IDs will remain until we switch from storing tables/indices/zones in the Configuration to storing them in the Catalog (this is out of scope of this task). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18979) Add snapshot creation time in SnapshotView
[ https://issues.apache.org/jira/browse/IGNITE-18979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-18979: Description: Currently SnapshotView doesn't show snapshot creation time. Currently this value can be extracted from metrics (snapshot.endTime), but: # it shows only on the snapshot initiator node # this value is not persisted # it is overrided after new snapshot created. >From other hand it's useful get info about when full/incremental snapshot was >created. was: Currently SnapshotView doesn't show snapshot creation time. This value can be extracted from metrics (snapshot.endTime), but: # it shows only on the snapshot initiator node # this value is not persisted # it is overrided after new snapshot created. >From other hand it's useful get info about when last full/incremental snapshot >was created. > Add snapshot creation time in SnapshotView > -- > > Key: IGNITE-18979 > URL: https://issues.apache.org/jira/browse/IGNITE-18979 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Timonin >Priority: Major > Labels: IEP-89, ise > > Currently SnapshotView doesn't show snapshot creation time. Currently this > value can be extracted from metrics (snapshot.endTime), but: > # it shows only on the snapshot initiator node > # this value is not persisted > # it is overrided after new snapshot created. > From other hand it's useful get info about when full/incremental snapshot was > created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19547) Switch index IDs from UUID to int
Roman Puchkovskiy created IGNITE-19547: -- Summary: Switch index IDs from UUID to int Key: IGNITE-19547 URL: https://issues.apache.org/jira/browse/IGNITE-19547 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 Currently, as indices are stored as named list items in the Configuration, they are internally (to the configuration) identified by UUIDs. The same UUIDs are also used to identify indices in the whole system. We need to change the latter: that is, in addition to the internal IDs (needed only for configuration), we need to generate integer IDs and use them in the rest of the system to identify indices. Internal IDs will remain until we switch from storing tables/indices/zones in the Configuration to storing them in the Catalog (this is out of scope of this task). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19538) Thin 3.0: Data streamer IEP
[ https://issues.apache.org/jira/browse/IGNITE-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-19538. - Resolution: Fixed https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer > Thin 3.0: Data streamer IEP > --- > > Key: IGNITE-19538 > URL: https://issues.apache.org/jira/browse/IGNITE-19538 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Prepare an IEP for Ignite 3 data streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19546) .NET: Thin 3.0: Data Streamer with Receiver
[ https://issues.apache.org/jira/browse/IGNITE-19546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19546: Description: Implement data streamer with receiver in .NET client - see Use Case 2 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. (was: Implement data streamer with receiver in Java client - see Use Case 2 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer].) > .NET: Thin 3.0: Data Streamer with Receiver > --- > > Key: IGNITE-19546 > URL: https://issues.apache.org/jira/browse/IGNITE-19546 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement data streamer with receiver in .NET client - see Use Case 2 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19546) .NET: Thin 3.0: Data Streamer with Receiver
[ https://issues.apache.org/jira/browse/IGNITE-19546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19546: Labels: .NET iep-102 ignite-3 (was: iep-102 ignite-3) > .NET: Thin 3.0: Data Streamer with Receiver > --- > > Key: IGNITE-19546 > URL: https://issues.apache.org/jira/browse/IGNITE-19546 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement data streamer with receiver in .NET client - see Use Case 2 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19545) .NET: Thin 3.0: Basic Data Streamer
Pavel Tupitsyn created IGNITE-19545: --- Summary: .NET: Thin 3.0: Basic Data Streamer Key: IGNITE-19545 URL: https://issues.apache.org/jira/browse/IGNITE-19545 Project: Ignite Issue Type: Task Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement basic data streamer in Java client without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19545) .NET: Thin 3.0: Basic Data Streamer
[ https://issues.apache.org/jira/browse/IGNITE-19545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19545: Labels: .NET iep-102 ignite-3 (was: iep-102 ignite-3) > .NET: Thin 3.0: Basic Data Streamer > --- > > Key: IGNITE-19545 > URL: https://issues.apache.org/jira/browse/IGNITE-19545 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement basic data streamer in .NET client without receiver - see Use Case > 1 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19546) .NET: Thin 3.0: Data Streamer with Receiver
Pavel Tupitsyn created IGNITE-19546: --- Summary: .NET: Thin 3.0: Data Streamer with Receiver Key: IGNITE-19546 URL: https://issues.apache.org/jira/browse/IGNITE-19546 Project: Ignite Issue Type: Task Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement data streamer with receiver in Java client - see Use Case 2 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19545) .NET: Thin 3.0: Basic Data Streamer
[ https://issues.apache.org/jira/browse/IGNITE-19545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19545: Description: Implement basic data streamer in .NET client without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. (was: Implement basic data streamer in Java client without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer].) > .NET: Thin 3.0: Basic Data Streamer > --- > > Key: IGNITE-19545 > URL: https://issues.apache.org/jira/browse/IGNITE-19545 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement basic data streamer in .NET client without receiver - see Use Case > 1 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19544) Thin 3.0: Data Streamer with Receiver
Pavel Tupitsyn created IGNITE-19544: --- Summary: Thin 3.0: Data Streamer with Receiver Key: IGNITE-19544 URL: https://issues.apache.org/jira/browse/IGNITE-19544 Project: Ignite Issue Type: Task Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Implement basic data streamer in Java client without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19544) Thin 3.0: Data Streamer with Receiver
[ https://issues.apache.org/jira/browse/IGNITE-19544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19544: Description: Implement data streamer with receiver in Java client - see Use Case 2 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. (was: Implement basic data streamer in Java client without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer].) > Thin 3.0: Data Streamer with Receiver > - > > Key: IGNITE-19544 > URL: https://issues.apache.org/jira/browse/IGNITE-19544 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement data streamer with receiver in Java client - see Use Case 2 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19540) Thin 3.0: Basic Data Streamer
[ https://issues.apache.org/jira/browse/IGNITE-19540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19540: Description: Implement basic data streamer in Java client without receiver - see Use Case 1 in the [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. (was: Implement basic data streamer in Java client without receiver.) > Thin 3.0: Basic Data Streamer > - > > Key: IGNITE-19540 > URL: https://issues.apache.org/jira/browse/IGNITE-19540 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-102, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement basic data streamer in Java client without receiver - see Use Case > 1 in the > [IEP-102|https://cwiki.apache.org/confluence/display/IGNITE/IEP-102%3A+Data+Streamer]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19533) Rename UNKNOWN_ERR error code to INTERNAL_ERR
[ https://issues.apache.org/jira/browse/IGNITE-19533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19533: - Description: The UNKNOWN_ERR error code should be renamed to INTRNAL_ERR. The @Deprecated should be removed as well. The INTRNAL_ERR error code should be considered as the product's internal error caused by faulty logic or coding in the product. In general, this error code represents a non-recoverable error that should be provided to code maintainers. It seems to me the UNEXPECTED_ERR error code just duplicates `INTERNAL_ERR` one, so, it should be removed. was: The UNEXPECTED_ERR error code should be renamed to INTRNAL_ERR. The @Deprecated should be removed as well. The INTRNAL_ERR error code should be considered as the product's internal error caused by faulty logic or coding in the product. In general, this error code represents a non-recoverable error that should be provided to code maintainers. > Rename UNKNOWN_ERR error code to INTERNAL_ERR > - > > Key: IGNITE-19533 > URL: https://issues.apache.org/jira/browse/IGNITE-19533 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: iep-84, ignite-3 > Fix For: 3.0.0-beta2 > > > The UNKNOWN_ERR error code should be renamed to INTRNAL_ERR. The @Deprecated > should be removed as well. > The INTRNAL_ERR error code should be considered as the product's internal > error caused by faulty logic or coding in the product. In general, this error > code represents a non-recoverable error that should be provided to code > maintainers. > It seems to me the UNEXPECTED_ERR error code just duplicates `INTERNAL_ERR` > one, so, it should be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19533) Rename UNKNOWN_ERR error code to INTERNAL_ERR
[ https://issues.apache.org/jira/browse/IGNITE-19533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19533: - Summary: Rename UNKNOWN_ERR error code to INTERNAL_ERR (was: Rename UNEXPECTED_ERR error code to INTERNAL_ERR) > Rename UNKNOWN_ERR error code to INTERNAL_ERR > - > > Key: IGNITE-19533 > URL: https://issues.apache.org/jira/browse/IGNITE-19533 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: iep-84, ignite-3 > Fix For: 3.0.0-beta2 > > > The UNEXPECTED_ERR error code should be renamed to INTRNAL_ERR. The > @Deprecated should be removed as well. > The INTRNAL_ERR error code should be considered as the product's internal > error caused by faulty logic or coding in the product. In general, this error > code represents a non-recoverable error that should be provided to code > maintainers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
