{"action":"created","issue":{"url":"https://api.github.com/repos/EVODelavega/phpkafka/issues/3","labels_url":"https://api.github.com/repos/EVODelavega/phpkafka/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/EVODelavega/phpkafka/issues/3/comments","events_url":"https://api.github.com/repos/EVODelavega/phpkafka/issues/3/events","html_url":"https://github.com/EVODelavega/phpkafka/pull/3","id":107289836,"number":3,"title":"Producer timeouts","user":{"login":"orls","id":155430,"avatar_url":"https://avatars.githubusercontent.com/u/155430?v=3","gravatar_id":"","url":"https://api.github.com/users/orls","html_url":"https://github.com/orls","followers_url":"https://api.github.com/users/orls/followers","following_url":"https://api.github.com/users/orls/following{/other_user}","gists_url":"https://api.github.com/users/orls/gists{/gist_id}","starred_url":"https://api.github.com/users/orls/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/orls/subscriptions","organizations_url":"https://api.github.com/users/orls/orgs","repos_url":"https://api.github.com/users/orls/repos","events_url":"https://api.github.com/users/orls/events{/privacy}","received_events_url":"https://api.github.com/users/orls/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-09-18T22:38:56Z","updated_at":"2015-09-24T10:06:50Z","closed_at":"2015-09-21T08:02:07Z","pull_request":{"url":"https://api.github.com/repos/EVODelavega/phpkafka/pulls/3","html_url":"https://github.com/EVODelavega/phpkafka/pull/3","diff_url":"https://github.com/EVODelavega/phpkafka/pull/3.diff","patch_url":"https://github.com/EVODelavega/phpkafka/pull/3.patch"},"body":"Support setting timeouts to all produce variants.\r\n\r\nAlso fixes a bug with an uninitialised obj in the CONFIRM_EXTENDED support"},"comment":{"url":"https://api.github.com/repos/EVODelavega/phpkafka/issues/comments/142880736","html_url":"https://github.com/EVODelavega/phpkafka/pull/3#issuecomment-142880736","issue_url":"https://api.github.com/repos/EVODelavega/phpkafka/issues/3","id":142880736,"user":{"login":"EVODelavega","id":647725,"avatar_url":"https://avatars.githubusercontent.com/u/647725?v=3","gravatar_id":"","url":"https://api.github.com/users/EVODelavega","html_url":"https://github.com/EVODelavega","followers_url":"https://api.github.com/users/EVODelavega/followers","following_url":"https://api.github.com/users/EVODelavega/following{/other_user}","gists_url":"https://api.github.com/users/EVODelavega/gists{/gist_id}","starred_url":"https://api.github.com/users/EVODelavega/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/EVODelavega/subscriptions","organizations_url":"https://api.github.com/users/EVODelavega/orgs","repos_url":"https://api.github.com/users/EVODelavega/repos","events_url":"https://api.github.com/users/EVODelavega/events{/privacy}","received_events_url":"https://api.github.com/users/EVODelavega/received_events","type":"User","site_admin":false},"created_at":"2015-09-24T10:06:50Z","updated_at":"2015-09-24T10:06:50Z","body":"@edenhill That's the direction I want this extension to go in. What I want to end up with is a structure like this:\r\n\r\nKafka(string brokers, array config) <-- this would actually be the `rd_kafka_conf_t` inteface\r\n\r\nKafka::getTopic(string topic, int mode) <-- this holds the `rd_kafka_topic_t`, the config, actually opens a connection and holds the topic meta. Depending on the mode, the KafkaTopic instance is a producer or a consumer\r\n\r\nKafkaTopic::produceBatch(array messages, ...) & KafkaTopic::consumeBatch(...) These methods will return a queue (KafkaQueue), which would, in turn be configurable to some degree. I might split up these classes into `KafkaProducer` and `KafkaConsumer`, each linked to a specific topic, for clarity. Same goes for the Queue instances I'm returning.\r\n\r\nThe way shared resources (`rd_kafka_t` and its config, meta structs etc...) are managed needs more thought than I had originally put into it. It's more than likely (in fact, it's a must) to share a connection, its config and the metadata over three instances. Exposing the config is really quite risky at times, eg:\r\n\r\n```php\r\n$kafka = new Kafka($broker, $someConf);\r\n$produceFoo = $kafka->getTopic('foo', Kafka::MODE_PRODUCER);\r\n$secondProducer = $kafka->getTopic('foo', Kafka::MODE_PRODUCER);\r\n$consumeFoo = $kafka->getTopic('foo', Kafka::MODE_CONSUMER);\r\n```\r\nAll three `KafkaTopic` instances should share the same meta struct, and the first two, both being producers should share the same resources throughout, but if the user does something like this:\r\n\r\n```php\r\n$queue = $produceFoo->produceBatch(\r\n    $hugeArray,\r\n    [\r\n        \"queue.buffering.max.messages\" => count($hugeArray),\r\n        \"queue.buffering.max.ms\"            => count($hugeArray)*100,//100ms per msg\r\n    ]\r\n);//async produce call\r\n$secondProducer->produce(\"simple msg\", [\"queue.buffering.max.ms\" => 1000]);\r\n```\r\n\r\nThat might block PHP's RSHUTDOWN sequence, if the connection was set up to empty its buffers before closing...\r\n\r\nI hope all of this dribble makes sense. I'll have some spare time on my hands over the next couple of days, and I'm planning to work some more on this project this weekend."}}