+1 Great digging, Sergey!
Sergey Soldatov wrote:
James,
Sure. I will file a JIRA and check about non zero thread pool size (not
sure that would help since it's initialized in getDefaultExecutor and
always used if no other pool is provided in HTable constructor).
Thanks,
Sergey
On Mon, May 23, 2
James,
Sure. I will file a JIRA and check about non zero thread pool size (not
sure that would help since it's initialized in getDefaultExecutor and
always used if no other pool is provided in HTable constructor).
Thanks,
Sergey
On Mon, May 23, 2016 at 8:11 PM, James Taylor
wrote:
> Thanks, Serg
Thanks, Sergey. Sounds like you're on to it. We could try configuring those
tests with a non zero thread pool size so they don't
use SynchronousQueue. Want to file a JIRA with this info so we don't lose
track of it?
James
On Tue, May 17, 2016 at 11:21 PM, Sergey Soldatov
wrote:
> Getting ba
Getting back to the failures with OOM/unable to create a native thread.
Those files have around 100 tests inside each that are running on top of
the phoenix. In total they generate over 2500 scans. (system.catalog,
sequences and regular scans over table). The problem that on HBase side
all scans a
Looks like all Jenkins builds are failing, but it seems environmental? Do
we need to exclude some particular kind of host(s)?
On Wed, May 4, 2016 at 5:25 PM, James Taylor wrote:
> Thanks, Sergey!
>
> On Wed, May 4, 2016 at 5:22 PM, Sergey Soldatov
> wrote:
>
>> James,
>> Ah, didn't notice that
Thanks, Sergey!
On Wed, May 4, 2016 at 5:22 PM, Sergey Soldatov
wrote:
> James,
> Ah, didn't notice that timeouts are not shown in the final report as
> failures. It seems that the build is using JDK 1.7 and test run OOM
> with PermGen space. Fixed in PHOENIX-2879
>
> Thanks,
> Sergey
>
> On Wed
James,
Ah, didn't notice that timeouts are not shown in the final report as
failures. It seems that the build is using JDK 1.7 and test run OOM
with PermGen space. Fixed in PHOENIX-2879
Thanks,
Sergey
On Wed, May 4, 2016 at 1:48 PM, James Taylor wrote:
> Sergey, on master branch (which is HBase
Sergey, on master branch (which is HBase 1.2):
https://builds.apache.org/job/Phoenix-master/1214/console
On Wed, May 4, 2016 at 1:31 PM, Sergey Soldatov
wrote:
> James,
> Regarding HivePhoenixStoreIT. Are you talking about
> Phoenix-4.x-HBase-1.0 job? Last build passed it successfully.
>
>
> On
James,
Regarding HivePhoenixStoreIT. Are you talking about
Phoenix-4.x-HBase-1.0 job? Last build passed it successfully.
On Wed, May 4, 2016 at 10:15 AM, James Taylor wrote:
> Our Jenkins builds have improved, but we're seeing some issues:
> - timeouts with the new org.apache.phoenix.hive.HiveP
Our Jenkins builds have improved, but we're seeing some issues:
- timeouts with the new org.apache.phoenix.hive.HivePhoenixStoreIT test.
- consistent failure with 4.x-HBase-1.1 build. I suspect that Jenkins build
is out-of-date, as we haven't had a 4.x-HBase-1.1 branch for quite a while.
There's li
The defaults when tests are running are much lower than the standard
Phoenix defaults (see QueryServicesTestImpl and
BaseTest.setUpConfigForMiniCluster()). It's unclear to me why the
HashJoinIT and SortMergeJoinIT tests (I think these are the culprits) do
not seem to adhere to these (or maybe overr
The default thread pool sizes for HDFS, HBase, ZK, and the Phoenix client
are all contributing to this huge thread count.
A good starting point would be to take a jstack of the IT process and
count, group by threads with similar name. Reconfigure to reduce all those
groups to something like 10 eac
but the way, we need to do something with those OOMs and "unable to
create new native thread" in ITs. It's quite strange to see in 10
lines test such kind of failures. Especially when queries for table
with less than 10 rows generate over 2500 threads. Does anybody know
whether it's zk related issu
A patch would be much appreciated, Sergey.
On Fri, Apr 29, 2016 at 3:26 AM, Sergey Soldatov
wrote:
> As for flume module - flume-ng is coming with commons-io 2.1 while
> hadoop & hbase require org.apache.commons.io.Charsets which was
> introduced in 2.3. Easy way is to move dependency on flume-n
As for flume module - flume-ng is coming with commons-io 2.1 while
hadoop & hbase require org.apache.commons.io.Charsets which was
introduced in 2.3. Easy way is to move dependency on flume-ng after
the dependencies on hbase/hadoop.
The last thing about ConcurrentHashMap - it definitely means that
Thanks for looking into this, Josh - really appreciate it.
The NewerTableAlreadyExistsException occurs if a test derived from
BaseClientManagedTimeIT does not set the CURRENT_SCN_ATTRIB property on the
connection when creating a table. This will end up occurring in a
*different* test than the test
Also, didn't mean to ignore you Sergey. I haven't seen anything at the
moment which pointed to getting more info from -X (general flakiness
from the ASF jenkins boxes is... the norm).
We can definitely do this if we think there is something concrete that
we're missing.
Sergey Soldatov wrote:
*tl;dr*
* I'm removing ubuntu-us1 from all pools
* Phoenix-Flume ITs look busted
* UpsertValuesIT looks busted
* Something is weirdly wrong with Phoenix-4.x-HBase-1.1 in its entirety.
Details below...
It looks like we have a bunch of different reasons for the failures.
Starting with Phoenix-ma
Can we add -X to the mvn? All recent failures happen right before
integration tests started without any reasonable error message.
Possible an additional debug info would help.
Thanks,
Sergey
On Tue, Apr 26, 2016 at 3:47 PM, James Taylor wrote:
> Anyone know why our Jenkins builds keep failing? I
Anyone know why our Jenkins builds keep failing? Is it environmental and is
there anything we can do about it?
Thanks,
James
20 matches
Mail list logo
