Problem in the build server

[Francisco Figueiredo Jr.]

Hi all!

Yesterday, while running the tests in the build server to test PR #281, I noticed that the tests are hanging in the NpgsqlTests.CommandTests.ConnectionStringWithInvalidParameterValue

I'm checking the problem. It is odd that I can't reproduce the problem in my dev machine. The test pass ok here. :(

This is the error log:

https://build.npgsql.org/viewLog.html?buildId=1508&tab=buildResultsDiv&buildTypeId=npgsql_net45#testNameId-4569779020404025238

--
Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://gplus.to/franciscojunior
http://fxjr.blogspot.com
http://twitter.com/franciscojunior

[Francisco Figueiredo Jr.]

The problem seemed to start when we turned Npgsql logging on.

It is very odd that only this test is having problems... :(

I can confirm the problem is indeed with the logging. I created a test pull request disabling the log and the tests run ok without hangs:
https://build.npgsql.org/viewLog.html?tab=buildLog&buildTypeId=npgsql_net40&buildId=1519

I continue to not be able to reproduce this problem in my dev machine.

Are you able to reproduce it in your dev environment?

[Shay Rojansky]

Hey Francisco, I'll try to take a look at this tomorrow, I think it was my fault...

--
You received this message because you are subscribed to the Google Groups "Npgsql Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to npgsql-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francisco Figueiredo Jr.]

On Fri, Jul 18, 2014 at 5:46 PM, Shay Rojansky <ro...@roji.org> wrote:

Hey Francisco, I'll try to take a look at this tomorrow, I think it was my fault...

Hi, Shay!

Thank you very much for having a look at it.

And don't worry. I don't think it was your fault. Npgsql hags waiting for a response of the server. It starts the authentication handling  and stops there when reading the response just before receiving the error message about an invalid user. And just happens with this single method. :(

 

[Shay Rojansky]

Francisco, I disabled the logging in the unit tests and the problem went away.

It's strange, I'm not sure how it created the issue. But on the other hand, the current debug logging is very verbose and it's a little hard to make sense of everything. This volume of logs will also fill up the build server disk very quickly, since it saves all the outputs historically.

So we I created issue #279 for us to work on npgsql logging, after that is done I suggest we try to enable unit test logging again and see what happens... Is that ok?

[Francisco Figueiredo Jr.]

Em 19/07/2014 04:40, "Shay Rojansky" <ro...@roji.org> escreveu:
>
> Francisco, I disabled the logging in the unit tests and the problem went away.
>

Great!

> It's strange, I'm not sure how it created the issue. But on the other hand, the current debug logging is very verbose and it's a little hard to make sense of everything. This volume of logs will also fill up the build server disk very quickly, since it saves all the outputs historically.
>

Yes. It is very strange. I also don't know why this happened.
I also think the logging is very verbose for the build server. I think it would be more useful when creating the test to check for a specific problem. The developer would enable it for the specific test she is working with and when it is done, it would be disabled.

What do you think?

> So we I created issue #279 for us to work on npgsql logging, after that is done I suggest we try to enable unit test logging again and see what happens... Is that ok?
>

Sure!
+1

[Shay Rojansky]

On Sat, Jul 19, 2014 at 3:58 PM, Francisco Figueiredo Jr. <francisco.f...@gmail.com> wrote:

Em 19/07/2014 04:40, "Shay Rojansky" <ro...@roji.org> escreveu:

>
> Francisco, I disabled the logging in the unit tests and the problem went away.
>

Great!

> It's strange, I'm not sure how it created the issue. But on the other hand, the current debug logging is very verbose and it's a little hard to make sense of everything. This volume of logs will also fill up the build server disk very quickly, since it saves all the outputs historically.
>

Yes. It is very strange. I also don't know why this happened.
I also think the logging is very verbose for the build server. I think it would be more useful when creating the test to check for a specific problem. The developer would enable it for the specific test she is working with and when it is done, it would be disabled.

What do you think?

I agree. In normal logging frameworks you have different levels (info, debug, trace) for different classes/components. The level of verbosity we have right now is a bit like "trace everywhere" - you get a lot of information about every little small detail (this method was called, bytes were written to the stream...). I think that after #279 we should have the unit tests running in "debug" mode, which shouldn't be very verbose, and a developer can decide to turn on "trace level" for any component/class they want (e.g. show me all outgoing SQL, show me all incoming backend messages). The main question in my mind is if we should integrate with something like Commons Logging, which itself dispatches to the various logging frameworks (NLog, log4net...). The disadvantage is that it would add an external dependency but it would give all the features we could ever want. I guess we can think about all this a bit later...