Re: Jira Suggestion
+1 > On 14 May 2019, at 20:10, Benedict Elliott Smith wrote: > > It will be possible to insert n/a. It will simply be a text field - Jira > doesn’t know anything about the concept of a SHA, and I don’t intend to > introduce validation logic. It’s just a logical and consistent place for it > to live, and a strong reminder to include it. My intention is for it to be a > text field supporting Jira markup, like Test and Doc Plan, so that we can > insert cleanly formatted links to GitHub just like we do now in comments. > > > >> On 14 May 2019, at 20:04, Dinesh Joshi wrote: >> >> I am +0.5 on this. I think it is a good idea. I want to ensure that we >> capture use-cases such as Tasks that may not have a git commit associated >> with them. There might be tickets that may have multiple git commits across >> repos. SVN commits may also need to be handled. >> >> Dinesh >> >>> On May 14, 2019, at 11:34 AM, Jeff Jirsa wrote: >>> >>> Please >>> >>> -- >>> Jeff Jirsa >>> >>> On May 14, 2019, at 7:53 AM, Benedict Elliott Smith wrote: How would people feel about introducing a field for the (git) commit SHA, to be required on (Jira) commit? The norm is that we comment the SHA, but given this is the norm perhaps we should codify it instead, while we have the chance? It would also make it easier to find. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Jira Suggestion
+1 here, though I also liked it when people made it an href in comments so my lazy ass busy and efficient self could click it. =/ On Wed, May 15, 2019 at 3:39 AM Sam Tunnicliffe wrote: > +1 > > > On 14 May 2019, at 20:10, Benedict Elliott Smith > wrote: > > > > It will be possible to insert n/a. It will simply be a text field - > Jira doesn’t know anything about the concept of a SHA, and I don’t intend > to introduce validation logic. It’s just a logical and consistent place > for it to live, and a strong reminder to include it. My intention is for > it to be a text field supporting Jira markup, like Test and Doc Plan, so > that we can insert cleanly formatted links to GitHub just like we do now in > comments. > > > > > > > >> On 14 May 2019, at 20:04, Dinesh Joshi wrote: > >> > >> I am +0.5 on this. I think it is a good idea. I want to ensure that we > capture use-cases such as Tasks that may not have a git commit associated > with them. There might be tickets that may have multiple git commits across > repos. SVN commits may also need to be handled. > >> > >> Dinesh > >> > >>> On May 14, 2019, at 11:34 AM, Jeff Jirsa wrote: > >>> > >>> Please > >>> > >>> -- > >>> Jeff Jirsa > >>> > >>> > On May 14, 2019, at 7:53 AM, Benedict Elliott Smith < > bened...@apache.org> wrote: > > How would people feel about introducing a field for the (git) commit > SHA, to be required on (Jira) commit? > > The norm is that we comment the SHA, but given this is the norm > perhaps we should codify it instead, while we have the chance? It would > also make it easier to find. > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Jira Suggestion
I should clarify that by “cleanly formatted link to GitHub” I meant supporting exactly this. > On 15 May 2019, at 14:17, Joshua McKenzie wrote: > > +1 here, though I also liked it when people made it an href in comments so > my lazy ass busy and efficient self could click it. =/ > > On Wed, May 15, 2019 at 3:39 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 14 May 2019, at 20:10, Benedict Elliott Smith >> wrote: >>> >>> It will be possible to insert n/a. It will simply be a text field - >> Jira doesn’t know anything about the concept of a SHA, and I don’t intend >> to introduce validation logic. It’s just a logical and consistent place >> for it to live, and a strong reminder to include it. My intention is for >> it to be a text field supporting Jira markup, like Test and Doc Plan, so >> that we can insert cleanly formatted links to GitHub just like we do now in >> comments. >>> >>> >>> On 14 May 2019, at 20:04, Dinesh Joshi wrote: I am +0.5 on this. I think it is a good idea. I want to ensure that we >> capture use-cases such as Tasks that may not have a git commit associated >> with them. There might be tickets that may have multiple git commits across >> repos. SVN commits may also need to be handled. Dinesh > On May 14, 2019, at 11:34 AM, Jeff Jirsa wrote: > > Please > > -- > Jeff Jirsa > > >> On May 14, 2019, at 7:53 AM, Benedict Elliott Smith < >> bened...@apache.org> wrote: >> >> How would people feel about introducing a field for the (git) commit >> SHA, to be required on (Jira) commit? >> >> The norm is that we comment the SHA, but given this is the norm >> perhaps we should codify it instead, while we have the chance? It would >> also make it easier to find. >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Jira Suggestion
I believe I read half your email, my brain assessed that I agreed w/you and understood what you were saying, and then bounced down the thread; that's completely on me and in no way a phrasing error on your part. You are 100% correct and are supporting my (apparently multiple) bad habits. +1 again! On Wed, May 15, 2019 at 9:19 AM Benedict Elliott Smith wrote: > I should clarify that by “cleanly formatted link to GitHub” I meant > supporting exactly this. > > > On 15 May 2019, at 14:17, Joshua McKenzie wrote: > > > > +1 here, though I also liked it when people made it an href in comments > so > > my lazy ass busy and efficient self could click it. =/ > > > > On Wed, May 15, 2019 at 3:39 AM Sam Tunnicliffe wrote: > > > >> +1 > >> > >>> On 14 May 2019, at 20:10, Benedict Elliott Smith > >> wrote: > >>> > >>> It will be possible to insert n/a. It will simply be a text field - > >> Jira doesn’t know anything about the concept of a SHA, and I don’t > intend > >> to introduce validation logic. It’s just a logical and consistent place > >> for it to live, and a strong reminder to include it. My intention is > for > >> it to be a text field supporting Jira markup, like Test and Doc Plan, so > >> that we can insert cleanly formatted links to GitHub just like we do > now in > >> comments. > >>> > >>> > >>> > On 14 May 2019, at 20:04, Dinesh Joshi wrote: > > I am +0.5 on this. I think it is a good idea. I want to ensure that we > >> capture use-cases such as Tasks that may not have a git commit > associated > >> with them. There might be tickets that may have multiple git commits > across > >> repos. SVN commits may also need to be handled. > > Dinesh > > > On May 14, 2019, at 11:34 AM, Jeff Jirsa wrote: > > > > Please > > > > -- > > Jeff Jirsa > > > > > >> On May 14, 2019, at 7:53 AM, Benedict Elliott Smith < > >> bened...@apache.org> wrote: > >> > >> How would people feel about introducing a field for the (git) commit > >> SHA, to be required on (Jira) commit? > >> > >> The norm is that we comment the SHA, but given this is the norm > >> perhaps we should codify it instead, while we have the chance? It would > >> also make it easier to find. > >> > - > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Jira Suggestion
Great. I’ll take these +1s as consent, and proceed. It’s not irrevocable if it suddenly turns super contentious, but I don't think that’s likely. > On 15 May 2019, at 14:36, Joshua McKenzie wrote: > > I believe I read half your email, my brain assessed that I agreed w/you and > understood what you were saying, and then bounced down the thread; that's > completely on me and in no way a phrasing error on your part. > > You are 100% correct and are supporting my (apparently multiple) bad > habits. +1 again! > > On Wed, May 15, 2019 at 9:19 AM Benedict Elliott Smith > wrote: > >> I should clarify that by “cleanly formatted link to GitHub” I meant >> supporting exactly this. >> >>> On 15 May 2019, at 14:17, Joshua McKenzie wrote: >>> >>> +1 here, though I also liked it when people made it an href in comments >> so >>> my lazy ass busy and efficient self could click it. =/ >>> >>> On Wed, May 15, 2019 at 3:39 AM Sam Tunnicliffe wrote: >>> +1 > On 14 May 2019, at 20:10, Benedict Elliott Smith wrote: > > It will be possible to insert n/a. It will simply be a text field - Jira doesn’t know anything about the concept of a SHA, and I don’t >> intend to introduce validation logic. It’s just a logical and consistent place for it to live, and a strong reminder to include it. My intention is >> for it to be a text field supporting Jira markup, like Test and Doc Plan, so that we can insert cleanly formatted links to GitHub just like we do >> now in comments. > > > >> On 14 May 2019, at 20:04, Dinesh Joshi wrote: >> >> I am +0.5 on this. I think it is a good idea. I want to ensure that we capture use-cases such as Tasks that may not have a git commit >> associated with them. There might be tickets that may have multiple git commits >> across repos. SVN commits may also need to be handled. >> >> Dinesh >> >>> On May 14, 2019, at 11:34 AM, Jeff Jirsa wrote: >>> >>> Please >>> >>> -- >>> Jeff Jirsa >>> >>> On May 14, 2019, at 7:53 AM, Benedict Elliott Smith < bened...@apache.org> wrote: How would people feel about introducing a field for the (git) commit SHA, to be required on (Jira) commit? The norm is that we comment the SHA, but given this is the norm perhaps we should codify it instead, while we have the chance? It would also make it easier to find. >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Running 4.0 (trunk) on Windows
Hi Devs,
Base question:
How to run Cassandra 4.0 (trunk) version on a Windows based environment
without getting always the errors like this?
org.apache.cassandra.io.FSReadError: java.io.IOException: Invalid folder
descriptor trying to create log replica
D:\workspace\java-projects\java-automated-test-suite\target\embeddedCassandra\data\test_keyspace\test_table-f6498e1075ca11e9a59ed3a612c57aaf
Background / Motivation:
In our project we want to use Map/List data types heavily - also
combined with IN operator. Due to
https://issues.apache.org/jira/browse/CASSANDRA-12654 this does not work
in 3.x but solved in 4.0. Also extended features around the above
complex data types in 4.0 excites me up. So I decided to do a test
deployment on our test servers (Linux based) - features worked like
charm there.
As a next step I extended our jBehave testing framework to also be able
to fire up an embedded Cassandra 4.0 for running tests. Since I am
developing on Windows I started to get the above mentioned FSReadError
exceptions however folder path is valid.
Same happens if I try to fire up Cassandra 4.0 instances on Windows systems.
More advanced question:
Based on stack traces I took a look into the source. In
org.apache.cassandra.db.lifecycle.LogReplica and e.g. in open(File file)
method (along with others) it is using the
NativeLibrary.tryOpenDirectory(file.getParentFile().getPath()) call - if
it fails I get the above FSReadError for sure.
And here we arrive to the main point... On Windows the
org.apache.cassandra.utils.NativeLibraryWindows class is used in the
background. But in this class basically almost all method implementation
is just "throw new UnsatisfiedLinkError();" - bingo! This shows me that
I have no really hope... If I am on Windows I will fail like hell with
above errors always.
1. Are you planning to do something around it?
What I did as an ass-saver I have added a "mock" implementation for 3
problematic methods by implementing in Java in NativeLibraryWindows
class fake_callOpen(), fake_callFsync(), fake_callClose() kinda
simulating something. fake_callOpen() stores the fake fdId => path
mapping in an internal Map object. fake_callClose() flushes that out.
fake_callFsync() gives a WARN if the fdId is uinknown (so
fake_callOpen() was not invoked earlier). Issue has gone for me after
this, Cassandra 4.0 runs fine with all of our test cases - I am happy!
:-) So and but...
2. My quick and dirty implementation shows that I regularly get lots of
warnings from my fake_callFsync(int fd): "file descriptor {} is unknown
so invalid!" which means callOpen(int fd) was NOT invoked in prior
calling callFsync() for the given descriptor. Is that normal??? Should
not callOpen() always be invoked??? Could it be a bug somehow???
3. I am really not planning ever run Cassandra (or any other) in Windows
based PROD system. But developing on Windows still. Wouldn't it make
sense to at least provide some workaround here for fellow developers
like me? At least to be able to run the server in Windows (for
testing/development purposes only) ...
thanks!
--
Attila Wind
http://www.linkedin.com/in/attilaw
Mobile: +36 31 7811355
Re: Running 4.0 (trunk) on Windows
Hi Attila,
Have you tried building & running Cassandra using Windows Subsystem for
Linux[1]? The integration is seamless and you get a full fledged Linux
environment on Windows. The overhead is minimal and you should be able to edit
in your IDE on Windows.
Thanks,
Dinesh
[1] https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
> On May 15, 2019, at 10:28 PM, Attila Wind wrote:
>
> Hi Devs,
>
> Base question:
> How to run Cassandra 4.0 (trunk) version on a Windows based environment
> without getting always the errors like this?
> org.apache.cassandra.io.FSReadError: java.io.IOException: Invalid folder
> descriptor trying to create log replica
> D:\workspace\java-projects\java-automated-test-suite\target\embeddedCassandra\data\test_keyspace\test_table-f6498e1075ca11e9a59ed3a612c57aaf
>
> Background / Motivation:
> In our project we want to use Map/List data types heavily - also combined
> with IN operator. Due to
> https://issues.apache.org/jira/browse/CASSANDRA-12654 this does not work in
> 3.x but solved in 4.0. Also extended features around the above complex data
> types in 4.0 excites me up. So I decided to do a test deployment on our test
> servers (Linux based) - features worked like charm there.
> As a next step I extended our jBehave testing framework to also be able to
> fire up an embedded Cassandra 4.0 for running tests. Since I am developing on
> Windows I started to get the above mentioned FSReadError exceptions however
> folder path is valid.
> Same happens if I try to fire up Cassandra 4.0 instances on Windows systems.
>
> More advanced question:
> Based on stack traces I took a look into the source. In
> org.apache.cassandra.db.lifecycle.LogReplica and e.g. in open(File file)
> method (along with others) it is using the
> NativeLibrary.tryOpenDirectory(file.getParentFile().getPath()) call - if it
> fails I get the above FSReadError for sure.
> And here we arrive to the main point... On Windows the
> org.apache.cassandra.utils.NativeLibraryWindows class is used in the
> background. But in this class basically almost all method implementation is
> just "throw new UnsatisfiedLinkError();" - bingo! This shows me that I have
> no really hope... If I am on Windows I will fail like hell with above errors
> always.
>
> 1. Are you planning to do something around it?
>
> What I did as an ass-saver I have added a "mock" implementation for 3
> problematic methods by implementing in Java in NativeLibraryWindows class
> fake_callOpen(), fake_callFsync(), fake_callClose() kinda simulating
> something. fake_callOpen() stores the fake fdId => path mapping in an
> internal Map object. fake_callClose() flushes that out. fake_callFsync()
> gives a WARN if the fdId is uinknown (so fake_callOpen() was not invoked
> earlier). Issue has gone for me after this, Cassandra 4.0 runs fine with all
> of our test cases - I am happy! :-) So and but...
>
> 2. My quick and dirty implementation shows that I regularly get lots of
> warnings from my fake_callFsync(int fd): "file descriptor {} is unknown so
> invalid!" which means callOpen(int fd) was NOT invoked in prior calling
> callFsync() for the given descriptor. Is that normal??? Should not callOpen()
> always be invoked??? Could it be a bug somehow???
>
> 3. I am really not planning ever run Cassandra (or any other) in Windows
> based PROD system. But developing on Windows still. Wouldn't it make sense to
> at least provide some workaround here for fellow developers like me? At least
> to be able to run the server in Windows (for testing/development purposes
> only) ...
>
> thanks!
>
> --
> Attila Wind
>
> http://www.linkedin.com/in/attilaw
> Mobile: +36 31 7811355
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Running 4.0 (trunk) on Windows
Hi Dinesh,
No. And I am not really planning to. Too early to start looking for
other workarounds I think (I could also put the whole stuff into a Linux
based Docker container and run from there if it gets to that point - its
supported by our everything) before it is confirmed fact that there is
no plan from Cassandra Devs to normally support Windows in Cassandra 4.0.
Currently it is not the case as far as I see so for now more interested
about intentions - that was the goal of my mail. Plus of course also
give myself a chance to let it turn out if I am missing a config options
somewhere somehow... :-) Code base is pretty big I absolutely have no
overview of course. Chance is high I am missing something... :-)
thanks
Attila Wind
http://www.linkedin.com/in/attilaw
Mobile: +36 31 7811355
On 2019. 05. 16. 7:49, Dinesh Joshi wrote:
Hi Attila,
Have you tried building & running Cassandra using Windows Subsystem for
Linux[1]? The integration is seamless and you get a full fledged Linux environment
on Windows. The overhead is minimal and you should be able to edit in your IDE on
Windows.
Thanks,
Dinesh
[1] https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
On May 15, 2019, at 10:28 PM, Attila Wind wrote:
Hi Devs,
Base question:
How to run Cassandra 4.0 (trunk) version on a Windows based environment without
getting always the errors like this?
org.apache.cassandra.io.FSReadError: java.io.IOException: Invalid folder
descriptor trying to create log replica
D:\workspace\java-projects\java-automated-test-suite\target\embeddedCassandra\data\test_keyspace\test_table-f6498e1075ca11e9a59ed3a612c57aaf
Background / Motivation:
In our project we want to use Map/List data types heavily - also combined with
IN operator. Due to https://issues.apache.org/jira/browse/CASSANDRA-12654 this
does not work in 3.x but solved in 4.0. Also extended features around the above
complex data types in 4.0 excites me up. So I decided to do a test deployment
on our test servers (Linux based) - features worked like charm there.
As a next step I extended our jBehave testing framework to also be able to fire
up an embedded Cassandra 4.0 for running tests. Since I am developing on
Windows I started to get the above mentioned FSReadError exceptions however
folder path is valid.
Same happens if I try to fire up Cassandra 4.0 instances on Windows systems.
More advanced question:
Based on stack traces I took a look into the source. In
org.apache.cassandra.db.lifecycle.LogReplica and e.g. in open(File file) method
(along with others) it is using the
NativeLibrary.tryOpenDirectory(file.getParentFile().getPath()) call - if it
fails I get the above FSReadError for sure.
And here we arrive to the main point... On Windows the
org.apache.cassandra.utils.NativeLibraryWindows class is used in the background. But in
this class basically almost all method implementation is just "throw new
UnsatisfiedLinkError();" - bingo! This shows me that I have no really hope... If I
am on Windows I will fail like hell with above errors always.
1. Are you planning to do something around it?
What I did as an ass-saver I have added a "mock" implementation for 3 problematic
methods by implementing in Java in NativeLibraryWindows class fake_callOpen(),
fake_callFsync(), fake_callClose() kinda simulating something. fake_callOpen() stores the
fake fdId => path mapping in an internal Map object. fake_callClose() flushes that out.
fake_callFsync() gives a WARN if the fdId is uinknown (so fake_callOpen() was not invoked
earlier). Issue has gone for me after this, Cassandra 4.0 runs fine with all of our test
cases - I am happy! :-) So and but...
2. My quick and dirty implementation shows that I regularly get lots of warnings from my
fake_callFsync(int fd): "file descriptor {} is unknown so invalid!" which means
callOpen(int fd) was NOT invoked in prior calling callFsync() for the given descriptor.
Is that normal??? Should not callOpen() always be invoked??? Could it be a bug somehow???
3. I am really not planning ever run Cassandra (or any other) in Windows based
PROD system. But developing on Windows still. Wouldn't it make sense to at
least provide some workaround here for fellow developers like me? At least to
be able to run the server in Windows (for testing/development purposes only) ...
thanks!
--
Attila Wind
http://www.linkedin.com/in/attilaw
Mobile: +36 31 7811355
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
