February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1912) LockService can fail under heavy load

by Chris Gentile (JIRA)

[ https://issues.jboss.org/browse/JGRP-1912?page=com.atlassian.jira.plugin.... ] Chris Gentile updated JGRP-1912: -------------------------------- Attachment: LockServiceTestClient.java > LockService can fail under heavy load > ------------------------------------- > > Key: JGRP-1912 > URL: https://issues.jboss.org/browse/JGRP-1912 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: both windows 8.1 and RHEL > java 1.7.0_75 > Reporter: Chris Gentile > Assignee: Bela Ban > Attachments: LockServiceTestClient.java > > > Once in awhile, the LockService will get stuck acquiring a lock. > These seems to occur most often when two threads are simultaneously trying to acquire the same lock. (i.e.: exact same millisecond on a server with multiple processors). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1912) LockService can fail under heavy load

by Chris Gentile (JIRA)

[ https://issues.jboss.org/browse/JGRP-1912?page=com.atlassian.jira.plugin.... ] Chris Gentile commented on JGRP-1912: ------------------------------------- I need to attach the test driver (a single .java file). I can't figure out how to make the Attachments visible so that I can add a file. > LockService can fail under heavy load > ------------------------------------- > > Key: JGRP-1912 > URL: https://issues.jboss.org/browse/JGRP-1912 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: both windows 8.1 and RHEL > java 1.7.0_75 > Reporter: Chris Gentile > Assignee: Bela Ban > > Once in awhile, the LockService will get stuck acquiring a lock. > These seems to occur most often when two threads are simultaneously trying to acquire the same lock. (i.e.: exact same millisecond on a server with multiple processors). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-686?page=com.atlassian.jira.plugin... ] Petr Široký commented on DROOLS-686: ------------------------------------ I will try to find some time this week to build the snapshots and verify the build locally. Thanks for the pointers [~ge0ffrey] . > Documentation build: Upgrade pressgang-tools from 2 to 3 > -------------------------------------------------------- > > Key: DROOLS-686 > URL: https://issues.jboss.org/browse/DROOLS-686 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Petr Široký > > We're still using pressgang-tools 2: > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook): > https://github.com/pressgang/pressgang-tools > However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us: > https://issues.jboss.org/browse/PRESSGANG-79 > The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core: > https://github.com/pressgang > Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy. > The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars. > In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1912) LockService can fail under heavy load

by Chris Gentile (JIRA)

[ https://issues.jboss.org/browse/JGRP-1912?page=com.atlassian.jira.plugin.... ] Chris Gentile updated JGRP-1912: -------------------------------- Environment: both windows 8.1 and RHEL java 1.7.0_75 > LockService can fail under heavy load > ------------------------------------- > > Key: JGRP-1912 > URL: https://issues.jboss.org/browse/JGRP-1912 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: both windows 8.1 and RHEL > java 1.7.0_75 > Reporter: Chris Gentile > Assignee: Bela Ban > > Once in awhile, the LockService will get stuck acquiring a lock. > These seems to occur most often when two threads are simultaneously trying to acquire the same lock. (i.e.: exact same millisecond on a server with multiple processors). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1912) LockService can fail under heavy load

by Chris Gentile (JIRA)

Chris Gentile created JGRP-1912: ----------------------------------- Summary: LockService can fail under heavy load Key: JGRP-1912 URL: https://issues.jboss.org/browse/JGRP-1912 Project: JGroups Issue Type: Bug Affects Versions: 3.6.1 Reporter: Chris Gentile Assignee: Bela Ban Once in awhile, the LockService will get stuck acquiring a lock. These seems to occur most often when two threads are simultaneously trying to acquire the same lock. (i.e.: exact same millisecond on a server with multiple processors). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4278) byte[] saved to Oracle BLOB can not be read back

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4278?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-4278: ------------------------------------ HHH-9263 looks like the Hibernate jira issue. [~gbadner], I think that this wfly-4278 issue is likely a duplicate of hhh-9263. Is there anything to be done as part of wfly-4278 or can I close it as a duplicate? Perhaps the attached test case might be helpful for hhh-9263. > byte[] saved to Oracle BLOB can not be read back > ------------------------------------------------ > > Key: WFLY-4278 > URL: https://issues.jboss.org/browse/WFLY-4278 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 8.2.0.Final > Environment: Linux 64bit, Oracle JDK 7 or 8, WildFly 8.2.0.Final > Reporter: Lubos Pechac > Assignee: Scott Marlow > Attachments: wildfly-testcase.zip > > > Since upgrading to Wildfly (Hibernate 4.3.7) we are experiencing problems persisting certain entities to an Oracle database. > The entity contains an attribute of type java.lang.Serializable and is mapped to an Oracle BLOB column. > When the value of the Serializable attribute is a byte[] then this is not properly serialized to the database. > The value stored does not correspond to the Java Object Serialization Specification, instead the exact contents of the byte array are saved, without the usual header information associated with Java Object Serialization. > > When we try to read this back from the database into our entity we get the exception shown below, so basically Hibernate cannot read what it wrote. > > We have attached a test case to demonstrate this problem. > > Caused by: org.hibernate.type.SerializationException: could not deserialize > at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:262) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.util.SerializationHelper.deserialize(SerializationHelper.java:306) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.fromBytes(SerializableTypeDescriptor.java:155) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:44) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.descriptor.sql.VarbinaryTypeDescriptor$2.doExtract(VarbinaryTypeDescriptor.java:71) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.loadFromResultSet(EntityReferenceInitializerImpl.java:324) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.hydrateEntityState(EntityReferenceInitializerImpl.java:251) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:107) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:255) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:129) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.loader.entity.plan.LegacyBatchingEntityLoaderBuilder$LegacyBatchingEntityLoader.load(LegacyBatchingEntityLoaderBuilder.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > ... 183 more > Caused by: java.io.StreamCorruptedException: invalid stream header: 63726561 > at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:804) [rt.jar:1.7.0_71] > at java.io.ObjectInputStream.<init>(ObjectInputStream.java:299) [rt.jar:1.7.0_71] > at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:328) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:318) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:237) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > ... 214 more -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1249) preparedStatementCacheHitCount / preparedStatementCacheMissCount should be long

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1249?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBJCA-1249. ------------------------------------ Resolution: Done > preparedStatementCacheHitCount / preparedStatementCacheMissCount should be long > ------------------------------------------------------------------------------- > > Key: JBJCA-1249 > URL: https://issues.jboss.org/browse/JBJCA-1249 > Project: IronJacamar > Issue Type: Task > Components: JDBC > Affects Versions: 1.0.30.Final, 1.1.9.Final, 1.2.2.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.1.10.Final, 1.2.3.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-715) Guvnor/BRMS field named 'valid' breaks UI

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-715?page=com.atlassian.jira.plugin... ] Michael Anstis commented on DROOLS-715: --------------------------------------- Unit test (operation also verified with the UI) *drools/drools-workbench-models* (master) http://github.com/droolsjbpm/drools/commit/70df6dc0a (6.2.x) http://github.com/droolsjbpm/drools/commit/078f76332 > Guvnor/BRMS field named 'valid' breaks UI > ----------------------------------------- > > Key: DROOLS-715 > URL: https://issues.jboss.org/browse/DROOLS-715 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR4 > Reporter: Daniel Daniel > Assignee: Michael Anstis > Fix For: 6.2.0.Final > > > I have a class called DrugDay, which has a boolean called valid. > In my WHEN block, > $drugDayA : DrugDay($uniqueIdA : uniqueId, $ctCodeA : ctCode, $dayA : day, valid == true) > having the condition, "valid == true", breaks the UI, with no error in the logs. The guided rule has to be deleted, and created again. It is happy without the "valid == true" condition. > Is this a reserved variable name? > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-715) Guvnor/BRMS field named 'valid' breaks UI

by Daniel Daniel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-715?page=com.atlassian.jira.plugin... ] Daniel Daniel commented on DROOLS-715: -------------------------------------- Ok thanks for verifying. It must be a Maven thing, or an outdated POJO being pulled in, because it just started breaking on this rule. I'll investigate further. > Guvnor/BRMS field named 'valid' breaks UI > ----------------------------------------- > > Key: DROOLS-715 > URL: https://issues.jboss.org/browse/DROOLS-715 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR4 > Reporter: Daniel Daniel > Assignee: Michael Anstis > Fix For: 6.2.0.Final > > > I have a class called DrugDay, which has a boolean called valid. > In my WHEN block, > $drugDayA : DrugDay($uniqueIdA : uniqueId, $ctCodeA : ctCode, $dayA : day, valid == true) > having the condition, "valid == true", breaks the UI, with no error in the logs. The guided rule has to be deleted, and created again. It is happy without the "valid == true" condition. > Is this a reserved variable name? > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-715) Guvnor/BRMS field named 'valid' breaks UI

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-715?page=com.atlassian.jira.plugin... ] Michael Anstis resolved DROOLS-715. ----------------------------------- Fix Version/s: 6.2.0.Final Resolution: Done > Guvnor/BRMS field named 'valid' breaks UI > ----------------------------------------- > > Key: DROOLS-715 > URL: https://issues.jboss.org/browse/DROOLS-715 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR4 > Reporter: Daniel Daniel > Assignee: Michael Anstis > Fix For: 6.2.0.Final > > > I have a class called DrugDay, which has a boolean called valid. > In my WHEN block, > $drugDayA : DrugDay($uniqueIdA : uniqueId, $ctCodeA : ctCode, $dayA : day, valid == true) > having the condition, "valid == true", breaks the UI, with no error in the logs. The guided rule has to be deleted, and created again. It is happy without the "valid == true" condition. > Is this a reserved variable name? > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2015