[GitHub] [pulsar-helm-chart] naveen1100 opened a new pull request #77: Bumping version

[GitBox]

naveen1100 opened a new pull request #77:
URL: https://github.com/apache/pulsar-helm-chart/pull/77


   ### Motivation
   Follow [Release 
process](https://github.com/apache/pulsar-helm-chart#release-process) to bump 
version
   
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Slack digest for #dev - 2020-10-27

[Apache Pulsar Slack]

2020-10-26 12:59:16 UTC - jia zhai: @Sijie Guo @Anup Ghatage right, there is no 
specific reason for this. It seems be more related to the project building,  we 
may need to config the profile to build different bc type. but this seems a 
little hard in maven:joy:.
It would be helpful, if anyone would like to contribute to this feature.

2020-10-26 16:31:57 UTC - Anup Ghatage: I’m thinking why not keep it on by 
default? There aren’t any API differences for the most part. That way Pulsar 
will be FIPS compliant all the time.

2020-10-26 17:05:50 UTC - Devin G. Bost: @Lari Hotari The reason I didn't 
finish the work on the flaky tests is because I ran out of time, and something 
odd I noticed (if I remember correctly) is that the changes caused 2-3 tests to 
fail more consistently. That's an unfortunate consequence of trying to fix too 
many of these flaky tests in one PR. 

I'm hoping to resume work on this in a few weeks.
+1 : Lari Hotari

2020-10-26 17:06:55 UTC - Devin G. Bost: Thanks for the feedback. I'll take a 
look at this one specifically.
+1 : Lari Hotari

2020-10-26 17:14:07 UTC - Lari Hotari: @Devin G. Bost You have already done a 
great effort on that PR. Are you ok if some of the changes in your PR get 
reused in smaller PRs asap? I believe it would be fair to use the 
 so that the original author (you) also gets credit for the final 
contribution in Github contribution stats.

2020-10-26 17:42:58 UTC - Devin G. Bost: Yes, I'm totally fine with that. 
Thanks for thinking of including me in the stats as a contributor.
+1 : Lari Hotari

2020-10-27 05:09:22 UTC - Lari Hotari: > I’d recommend to pull the commonly 
failed tests in one of the github issues and break it up.
@Sijie Guo Sounds like a plan. It looks like @eolivelli already created and 
fixed  , that was one of the 
common problems.
I realized that it's possible to find the failed builds of your own PRs in 
 by entering "is:failure 
actor:your_github_username" to the search. For example, my failed builds are 
 . 
I'll be going through the failed builds in the upcoming days. I'd suggest that 
others do this too so that we could together get the CI flakiness under control 
asap. We can always check for the recently filed flaky test issues before 
creating new issues so that we don't create duplicates. /cc @Penghui Li

2020-10-27 05:37:57 UTC - Lari Hotari: One of the common problems is the "Could 
not transfer artifact" error. `Could not transfer artifact 
org.objenesis:objenesis:jar:2.6 from/to central 
(): Transfer failed for 
:
 Connection reset`  . Already reported by Devin as 
 .

2020-10-27 05:57:00 UTC - Lari Hotari: PR to fix the maven download issue: 

Re: [ANNOUNCE] New Pulsar Committer: Huanli Meng & Hang Chen

[PengHui Li]

Congratulations huanli and hangchen

Penghui
On Oct 27, 2020, 11:56 AM +0800, dev@pulsar.apache.org, wrote:
>
> Congratulations !

[GitHub] [pulsar-helm-chart] naveen1100 commented on pull request #77: Bumping version

[GitBox]

naveen1100 commented on pull request #77:
URL: https://github.com/apache/pulsar-helm-chart/pull/77#issuecomment-717180281


   I want to bump the version but the checks are failing. Can someone please 
help with this.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-helm-chart] naveen1100 edited a comment on pull request #77: Bumping version

[GitBox]

naveen1100 edited a comment on pull request #77:
URL: https://github.com/apache/pulsar-helm-chart/pull/77#issuecomment-717180281


   I want to bump the version but the checks are failing. Can someone please 
help with this?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [pulsar-client-node] dlecocq opened a new issue #132: `AlreadyClosed` exception when using `topicsPattern`

[GitBox]

dlecocq opened a new issue #132:
URL: https://github.com/apache/pulsar-client-node/issues/132


   We are unable to cleanly close our consumer when using `topicsPattern`:
   
   ```
   2020-10-27 11:15:43.304 INFO  [0x7d6d5000] ConnectionPool:85 | Created 
connection for pulsar://pulsar.data-access-platform-portal.docker:6650
   2020-10-27 11:15:43.307 INFO  [0x7ef61000] ClientConnection:343 | 
[192.168.99.1:58802 -> 192.168.99.100:6650] Connected to broker
   Closing consumer...
   (node:35996) UnhandledPromiseRejectionWarning: Error: Failed to close 
consumer: AlreadyClosed
   (node:35996) UnhandledPromiseRejectionWarning: Unhandled promise rejection. 
This error originated either by throwing inside of an async function without a 
catch block, or by rejecting a promise which was not handled with .catch(). 
(rejection id: 1)
   (node:35996) [DEP0018] DeprecationWarning: Unhandled promise rejections are 
deprecated. In the future, promise rejections that are not handled will 
terminate the Node.js process with a non-zero exit code.
   ```
   
   That's the result from running this code snippet (with the appropriate 
docker container running):
   
   ```
   const Bluebird = require('bluebird')
   const Pulsar = require('pulsar-client')
   
   const doit = async () => {
 const client = new Pulsar.Client({
   webServiceUrl: 'http://pulsar.data-access-platform-portal.docker:8080',
   serviceUrl: 'pulsar://pulsar.data-access-platform-portal.docker:6650'
 })
 const consumer = await client.subscribe({
   topicsPattern: `non-persistent://public/default/topic`,
   subscription: 'test-subscription',
   subscriptionType: 'Shared',
   subscriptionInitialPosition: 'Earliest'
 })
   
 // Rather than push messages to consume, we're just waiting for a second
 await Bluebird.delay(1000)
   
 console.log('Closing consumer...')
 // We've also tried omitting this line, but it still produces errors
 await consumer.close()
 console.log('Closing client...')
 await client.close()
   }
   
   doit()
   ```
   
   We've tried this with node versions 10.16.3, 12.16.0, and 14.11.0 and pulsar 
2.6.1.
   
   I _suspect_ that the root cause is that it _appears_ that the consumer 
implementation in this library makes the assumption that there's only a single 
consumer - 
https://github.com/apache/pulsar-client-node/blob/f010fb2ed3c530af8006ba3d3a7b73c6b46f6507/src/Consumer.cc#L178
 overwrites the wrapper's consumer with each invocation. While this wouldn't be 
a problem with a single topic, it seems that the last consumer "wins" in that 
it gets stitched up to be the consumer saved in the wrapper. However, there may 
be a race condition for whether the listener handler stitched up correctly from 
the config 
(https://github.com/apache/pulsar-client-node/blob/f010fb2ed3c530af8006ba3d3a7b73c6b46f6507/src/Consumer.cc#L184
 but then the consumer config is subsequently deleted).
   
   Looking at `ClientImpl` in the pulsar C++ code, it appears that it also 
takes responsibility for closing any open consumers and producers, so we tried 
also just relying on the client in order to close the consumers (since 
`ClientImpl` appears to correctly track all newly-created consumers), but that 
_also_ reproduces with `AlreadyClosed` getting thrown.
   
   All that said, it is a little tricky to track all of it because of the 
number of levels of indirection - from the JS to the C++ extension to the C 
bindings which delegate out to the C++ client code. So we might be way off 😆 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org