| { |
| "core": { |
| "name": "APEXCORE", |
| "url": "https://issues.apache.org/jira/", |
| "jiras": [ |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919288", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919288", |
| "key": "APEXCORE-119", |
| "fields": { |
| "summary": "Add Support For A New Type Of (Distributed) Operator", |
| "description": "This JIRA Proposes support for a new type of distributed operator. Currently when an operator is partitioned there is no platform supported mechanism through which partitions can talk to each other. A Distributed operator would have an easy to use platform supported mechanism through which operators in a partitioning can exchange information with each other. Eventually Distributed operators would support running plain old single threaded java code transparently across partitions.\r\n\r\nIn summary the goals would be to do the following:\r\n\r\n1 - provide a platform supported fault tolerant mechanism through which operators in a partitioning can talk to each other.\r\n2 - provide a platform supported way to run plain old single threaded java code accross all the partitions of a Distributed operator\r\n\r\nThe benefits of implementing this would be huge:\r\n\r\n1 - Using distributed operators we could support large in memory fault tolerant data structures (graphs, maps, arrays) in a fault tolerant way. Like Spark's RDD's but better.\r\n2 - Plain old java code could be used to access and manipulate the data structures, without the user having the learn complex API's like with Spark.\r\n\r\nAn implementation proposal and presentation are coming soon.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919332", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919332", |
| "key": "APEXCORE-163", |
| "fields": { |
| "summary": "Dynamic application property changes", |
| "description": "Apex support modification of operator properties at runtime but the current implemenations has the following shortcomings.\r\n\r\n1. Property is not set across all partitions on the same window as individual partitions can be on different windows when property change is initiated from client resulting in inconsistency of data for those windows. I am being generous using the word inconsistent.\r\n2. Sometimes properties need to be set on more than one logical operators at the same time to achieve the change the user is seeking. Today they will be two separate changes happening on two different windows again resulting in inconsistent data for some windows. These would need to happen as a single transaction.\r\n3. If there is an operator failure before a committed checkpoint after an operator property is dynamically changed the operator will restart with the old property and the change will not be re-applied.\r\n\r\nTim and myself did some brainstorming and we have a proposal to overcome these shortcomings. The main problem in all the above cases is that the property changes are happening out-of-band of data flow and hence independent of windowing. The proposal is to bring the property change request into the in-band dataflow so that they are handled consistently with windowing and handled distributively.\r\n\r\nThe idea is to inject a special property change tuple containing the property changes and the identification information of the operator's they affect into the dataflow at the input operator. The tuple will be injected at window boundary after end window and before begin window and as this tuple flows through the DAG the intended operators properties will be modifed. They will all be modified consistently at the same window. The tuple can contain more than one property changes for more than one logical operators and the change will be applied consistently to the different logical operators at the same window. In case of failure the replay of tuples will ensure that the property change gets reapplied at the correct window.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919371", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919371", |
| "key": "APEXCORE-202", |
| "fields": { |
| "summary": "Integration with Samoa", |
| "description": "Apache Samoa[https://samoa.incubator.apache.org/] is an abstraction of a collections of streaming machine learning Algorithm. By far, it has integration with Samza, Storm and flink, It is a good start point for Apex to support streaming ML.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919400", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919400", |
| "key": "APEXCORE-231", |
| "fields": { |
| "summary": "Ability to configure attributes dynamically", |
| "description": "The Apex engine supports many platform level attributes like operator memory, application window count, container jvm options etc. Today these can only be set at application launch time and cannot be changed once the application is running.\r\n\r\nThis issue is to add the ability to change the attributes dynamically even as the application is running. The mechanics of an user requesting the attribute change can be similar to how a user requests property change via the command line client.\r\n\r\nSince each attribute is different the actual backend implementation to affect the changes will most likely be custom handling for different attributes but during the implementation process hopefully some common themes emerge and some amount of reuse possible.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919401", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919401", |
| "key": "APEXCORE-232", |
| "fields": { |
| "summary": "Ability to add new processing code to the DAG", |
| "description": "There are scenarios when new processing code needs to be added to an already running application. There are two scenarios.\r\n\r\na. A bug is discovered in an operator and an existing operator in the running DAG needs to be replaced. The platform supports shutting down and resuming an application which could be use as a first cut way to do this but there are a couple of drawbacks.\r\n i. This only works when the input source has memory, if it doesn't the messages received during the time the application is down are lost.\r\n ii. Depending on the complexity and state of the application it may take some time for this entire process and the application to get back to running state and this delay may not be acceptable for the downstream components that depend on the output of this application.\r\n\r\nb. A new operator needs to be added to the DAG to take data from an existing operator and do some additional processing. Today this is supported as long as the code for the operator is already in the application libraries. Often this will not be the case as users will not know what the operator will be beforehand when the application is originally launched.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919402", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919402", |
| "key": "APEXCORE-233", |
| "fields": { |
| "summary": "Ability to specify single instance objects in configuration", |
| "description": "There are scenarios where the same object instance needs to be specified for two attributes. Example is partitioner and stats listener, for partitioners that need to affect partitoning based on operator stats the same instance needs to be both. This is not possible to specify using a property file today as it will create two separate instances and can only be done in Java code today. The issue is to request adding this feature.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919403", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919403", |
| "key": "APEXCORE-234", |
| "fields": { |
| "summary": "Investigate other ways to specify properties in property files", |
| "description": "The current property file specification follows the hadoop configuration file format and this has led to some drawbacks. \r\n a. The names for the properties and attributes are verbose in the configuration file. \r\n b. When there are nested properties in operators the syntax deviates from the bean specification because it introduces some specific keywords in the specification like .prop and ,attr.\r\n\r\nThere will already be some changes afoot based on the following\r\n a. When adding ability to specify single instance attributes (https://malhar.atlassian.net/browse/APEXCORE-233) implementing it in the current syntax may not be possible or lead to very unwieldy syntax.\r\n b. There are also other ideas such as one from David to have the ability to specify global application level attributes which possible require rethinking the current syntax.\r\n\r\nUsers have also asked for an easier and more consistent way to specify these properties. This issue is to track the ideas and progress of these changes.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12919404", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12919404", |
| "key": "APEXCORE-235", |
| "fields": { |
| "summary": "Explicit support for batch processing", |
| "description": "Apex can be used for real-time and batch processing as it stands, but there are some aspects of batch processing that can be better supported through explicit constructs. This ticket can serve as umbrella for various features.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12922256", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12922256", |
| "key": "APEXCORE-289", |
| "fields": { |
| "summary": "Encrypted Streams in Apex DAG", |
| "description": "We should support encrypted streams in a DAG for Apex.\r\nBasically there will be 2 ways user can configure the streams for encryption:\r\n1) App wide attributes- Using which all the stream in the DAG will have encrypted channel.\r\n2) Stream based attribute - Using this user can set a certain stream to flow over encrypted channel.\r\n\r\nEncrypted for the streams should done at Network/Buffer Server levels.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12955374", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12955374", |
| "key": "APEXCORE-414", |
| "fields": { |
| "summary": "Native support for event-time windowing", |
| "description": "Apex core has streaming windows that establish a boundary based on arrival time of events. Many applications require boundaries based on the time of events, which could be a field in the tuple. Some of the operators support this today (time bucketing), but it would be good to provide more generic support for this in the engine itself. ", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12955475", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12955475", |
| "key": "APEXCORE-418", |
| "fields": { |
| "summary": "Support for Mesos", |
| "description": "Today Apex has two modes of execution: Embedded mode (everything running in a single JVM) and YARN. There has been a few questions around native support for Mesos. A cursory look suggests that Mesos support can be added by reimplementing the YARN specific portions in the master (AppMasterService, ContainerLauncher) and limited changes to the streaming container driver.\r\n\r\nMesos has a different model of resource allocation: The master offers resources to the framework while in YARN resources are requested. Apex master needs to implement the \"framework scheduler\" that is responsible to accept the resources and control the tasks.\r\n\r\nhttp://mesos.apache.org/documentation/latest/app-framework-development-guide/\r\n\r\nTasks are launched through executors, command line and docker executors are provided. \r\n\r\nApex also requires support to deploy the dependencies to the nodes on which the streaming containers are launched. YARN supports that through resource localization. Mesos supports this through the fetcher, which can copy the resources to the slave node.\r\n\r\nhttp://mesos.apache.org/documentation/latest/fetcher/\r\n", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| } |
| ], |
| "versions": [ |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12333945", |
| "id": "12333945", |
| "name": "3.0.1", |
| "archived": true, |
| "released": false, |
| "projectId": 12318823 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12335594", |
| "id": "12335594", |
| "name": "3.2.2", |
| "archived": false, |
| "released": false, |
| "projectId": 12318823 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12334814", |
| "id": "12334814", |
| "name": "3.3.1", |
| "archived": false, |
| "released": false, |
| "projectId": 12318823 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12335725", |
| "id": "12335725", |
| "name": "3.4.1", |
| "archived": false, |
| "released": false, |
| "projectId": 12318823 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12335724", |
| "id": "12335724", |
| "name": "3.5.0", |
| "archived": false, |
| "released": false, |
| "projectId": 12318823 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12333948", |
| "id": "12333948", |
| "name": "4.0.0", |
| "archived": false, |
| "released": false, |
| "projectId": 12318823 |
| } |
| ] |
| }, |
| "malhar": { |
| "name": "APEXMALHAR", |
| "url": "https://issues.apache.org/jira/", |
| "jiras": [ |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12926249", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12926249", |
| "key": "APEXMALHAR-1720", |
| "fields": { |
| "summary": "Development of Inner Join Operator", |
| "description": null, |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/3", |
| "description": "This issue is being actively worked on at the moment by the assignee.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/inprogress.png", |
| "name": "In Progress", |
| "id": "3", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/4", |
| "id": 4, |
| "key": "indeterminate", |
| "colorName": "yellow", |
| "name": "In Progress" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12926159", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12926159", |
| "key": "APEXMALHAR-1811", |
| "fields": { |
| "summary": "Add Non-Equality Join Condition", |
| "description": "Add new condition for non-equality join predicate (for example, user.zipcode != authzn.zipcode)", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12926152", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12926152", |
| "key": "APEXMALHAR-1818", |
| "fields": { |
| "summary": "Integrate Calcite to support SQL", |
| "description": "Once we have ability to generate a subdag, we should take a look at integrating Calcite into Apex. The operator that enables populate DAG, should use Calcite to generate the DAG, given a SQL query.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12926128", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12926128", |
| "key": "APEXMALHAR-1843", |
| "fields": { |
| "summary": "Split Malhar Library and Malhar Contrib package into baby packages", |
| "description": "[~andyp] I am assigning this to you cause you are the one who first said it. So either you lead it or find a willing lead to get this task to completion.\r\n\r\nThe problem with contrib and library modules of malhar is that a ton of dependencies are prescribed as optional. The motive behind it was that the users of these libraries are given an opportunity to keep the size of the dependency-included packages to bare minimum. It comes at a cost that the dependency now has to be manually figured out. This is a complete misuse of the optional dependency, IMO. It defeats the purpose of maven having dependency management as one of the biggest features of it.\r\n\r\nSo keep things sane - the proposed compromise is that we start creating smaller discreet packages for discrete technologies.", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/2", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/critical.png", |
| "name": "Critical", |
| "id": "2" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12926037", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12926037", |
| "key": "APEXMALHAR-1939", |
| "fields": { |
| "summary": "Stream API", |
| "description": null, |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/2", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/critical.png", |
| "name": "Critical", |
| "id": "2" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12924154", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12924154", |
| "key": "APEXMALHAR-1999", |
| "fields": { |
| "summary": "Running a Storm topology on Apex.", |
| "description": "Flink streaming is compatible with Apache Storm interfaces and therefore allows reusing code that was implemented for Storm.\r\nDetails can be found here.\r\nhttps://ci.apache.org/projects/flink/flink-docs-master/apis/storm_compatibility.html\r\nThis jira item can contain tasks for providing similar support in Apex", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12953482", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12953482", |
| "key": "APEXMALHAR-2026", |
| "fields": { |
| "summary": "Spill-able Datastructures", |
| "description": "Add libraryies for spooling datastructures to a key value store. There are several customer use cases which require spooled data structures.\r\n\r\n1 - Some operators like AbstractFileInputOperator have ever growing state. This is an issue because eventually the state of the operator will grow larger than the memory allocated to the operator, which will cause the operator to perpetually fail. However if the operator's datastructures are spooled then the operator will never run out of memory.\r\n\r\n2 - Some users have requested for the ability to maintain a map as well as a list of keys over which to iterate. Most key value stores don't provide this functionality. However, with spooled datastructures this functionality can be provided by maintaining a spooled map and an iterable set of keys.\r\n\r\n3 - Some users have requested building graph databases within APEX. This would require implementing a spooled graph data structure.\r\n\r\n4 - Another use case for spooled data structures is database operators. Database operators need to write data to a data base, but sometimes the database is down. In this case most of the database operators repeatedly fail until the database comes back up. In order to avoid constant failures the database operator need to writes data to a queue when the data base is down, then when the database is up the operator need to take data from the queue and write it to the database. In the case of a database failure this queue will grow larger than the total amount of memory available to the operator, so the queue should be spooled in order to prevent the operator from failing.\r\n\r\n5 - Any operator which needs to maintain a large data structure in memory currently needs to have that data serialized and written out to HDFS with every checkpoint. This is costly when the data structure is large. If the data structure is spooled, then only the changes to the data structure are written out to HDFS instead of the entire data structure.\r\n\r\n6 - Also building an Apex Native database for aggregations requires indices. These indices need to take the form of spooled data structures.\r\n\r\n7 - In the future any operator which needs to maintain a data structure larger than the memory available to it will need to spool the data structure.", |
| "fixVersions": [ |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12335815", |
| "id": "12335815", |
| "name": "3.5.0", |
| "archived": false, |
| "released": false |
| } |
| ], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/5", |
| "description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/resolved.png", |
| "name": "Resolved", |
| "id": "5", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/3", |
| "id": 3, |
| "key": "done", |
| "colorName": "green", |
| "name": "Complete" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12969033", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12969033", |
| "key": "APEXMALHAR-2089", |
| "fields": { |
| "summary": "Apache Beam support", |
| "description": "Apex should provide a runner for Beam. This ticket is a proxy for BEAM-261 as the implementation should probably live in the Beam repository.\r\n", |
| "fixVersions": [], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| }, |
| { |
| "expand": "operations,editmeta,changelog,transitions,renderedFields", |
| "id": "12988875", |
| "self": "https://issues.apache.org/jira/rest/api/2/issue/12988875", |
| "key": "APEXMALHAR-2142", |
| "fields": { |
| "summary": "High-level API window support", |
| "description": null, |
| "fixVersions": [ |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12335815", |
| "id": "12335815", |
| "name": "3.5.0", |
| "archived": false, |
| "released": false |
| } |
| ], |
| "priority": { |
| "self": "https://issues.apache.org/jira/rest/api/2/priority/3", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/priorities/major.png", |
| "name": "Major", |
| "id": "3" |
| }, |
| "status": { |
| "self": "https://issues.apache.org/jira/rest/api/2/status/1", |
| "description": "The issue is open and ready for the assignee to start work on it.", |
| "iconUrl": "https://issues.apache.org/jira/images/icons/statuses/open.png", |
| "name": "Open", |
| "id": "1", |
| "statusCategory": { |
| "self": "https://issues.apache.org/jira/rest/api/2/statuscategory/2", |
| "id": 2, |
| "key": "new", |
| "colorName": "blue-gray", |
| "name": "New" |
| } |
| } |
| } |
| } |
| ], |
| "versions": [ |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12334585", |
| "id": "12334585", |
| "name": "3.0.1", |
| "archived": true, |
| "released": false, |
| "projectId": 12318824 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12334590", |
| "id": "12334590", |
| "name": "3.2.1", |
| "archived": true, |
| "released": false, |
| "projectId": 12318824 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12334968", |
| "id": "12334968", |
| "name": "3.3.2", |
| "archived": false, |
| "released": false, |
| "projectId": 12318824 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12335827", |
| "id": "12335827", |
| "name": "3.4.1", |
| "archived": false, |
| "released": false, |
| "projectId": 12318824 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12335815", |
| "id": "12335815", |
| "name": "3.5.0", |
| "archived": false, |
| "released": false, |
| "projectId": 12318824 |
| }, |
| { |
| "self": "https://issues.apache.org/jira/rest/api/2/version/12334588", |
| "id": "12334588", |
| "name": "4.0.0", |
| "archived": false, |
| "released": false, |
| "projectId": 12318824 |
| } |
| ] |
| } |
| } |
