[JBoss JIRA] (JGRP-2241) Bundler using direct memory as buffer
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2241?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2241:
---------------------------
Fix Version/s: 4.0.14
(was: 4.0.13)
> Bundler using direct memory as buffer
> -------------------------------------
>
> Key: JGRP-2241
> URL: https://issues.jboss.org/browse/JGRP-2241
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.14
>
>
> The current bundler impls use a byte[] array in an output stream as buffer into which messages are written.
> If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate.
> Direct buffers can also be used on the receiver side, investigate.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2773) NPE when creating a new KieScanner
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2773?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2773:
--------------------------------
Sprint: 2018 Week 30-32
> NPE when creating a new KieScanner
> ----------------------------------
>
> Key: DROOLS-2773
> URL: https://issues.jboss.org/browse/DROOLS-2773
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.8.0.Final
> Reporter: Raphael Bowen Giudice
> Assignee: Mario Fusco
>
> When creating a new *KieScanner*, a *NullPointerException* is thrown. Here's the code where the *KieScanner* is created:
> {code:java}
> final KieServices kieServices = KieServices.Factory.get();
> final KieContainer kieContainer = kieServices.newKieContainer(
> kieServices.newReleaseId("mygroup", "rules", "1.0-SNAPSHOT"));
> final KieScanner kieScanner = kieServices.newKieScanner(kieContainer);
> {code}
> The method *indexArtifacts* in the *KieRepositoryScannerImpl* class, tries to index all the Maven artefacts.In my case, the artefact *sun.jdk:jconsole:jdk* cannot be resolved, which causes the *NullPointerException* in the line 399:
> {code:java}
> private Map<ReleaseId, DependencyDescriptor> indexArtifacts() {
> Map<ReleaseId, DependencyDescriptor> depsMap = new HashMap<ReleaseId, DependencyDescriptor>();
> for (DependencyDescriptor dep : artifactResolver.getAllDependecies()) {
> if ( !"test".equals(dep.getScope()) && !"provided".equals(dep.getScope()) && !"system".equals(dep.getScope()) ) {
> Artifact artifact = artifactResolver.resolveArtifact(dep.getReleaseId());
> log.debug( artifact + " resolved to " + artifact.getFile() ); // NPE happens here.
> if (isKJar(artifact.getFile())) {
> depsMap.put(adapt( dep.getReleaseIdWithoutVersion() ), new DependencyDescriptor(artifact));
> }
> } else {
> log.debug("{} does not need to be resolved because in scope {}", dep, dep.getScope());
> }
> }
> return depsMap;
> }
> {code}
> The curious part is that the *sun.jdk:jconsole:jdk* artefact is not declared in any of my projects or dependencies, as far as I could investigate.
> Here's the NPE stack trace:
> {code}
> Caused by: java.lang.NullPointerException: null
> at org.kie.scanner.KieRepositoryScannerImpl.indexArtifacts(KieRepositoryScannerImpl.java:399)
> at org.kie.scanner.KieRepositoryScannerImpl.setKieContainer(KieRepositoryScannerImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieScanner(KieServicesImpl.java:227)
> at com.test.ServiceConfoguration.kieContainer(ServiceConfoguration.java:84)
> at com.test.ServiceConfoguration$$EnhancerBySpringCGLIB$$4fd6caf2.CGLIB$kieContainer$2(<generated>)
> at com.test.ServiceConfoguration$$EnhancerBySpringCGLIB$$4fd6caf2$$FastClassBySpringCGLIB$$f73690dd.invoke(<generated>)
> at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
> at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:356)
> at com.test.ServiceConfoguration$$EnhancerBySpringCGLIB$$4fd6caf2.kieContainer(<generated>)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:162)
> ... 19 common frames omitted
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JGRP-2249) CENTRAL_LOCK2: reconciliation protocol on coord change
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2249?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2249:
--------------------------------
For now, conditions are not supported (beyond what's in the code already). If there is a need, we can always come back and support them...
> CENTRAL_LOCK2: reconciliation protocol on coord change
> ------------------------------------------------------
>
> Key: JGRP-2249
> URL: https://issues.jboss.org/browse/JGRP-2249
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> Implement a reconciliation protocol when the coord changes: instead of backing up all lock information to another member, the new coord asks all members for their current lock information (acquired locks, pending acquire and release requests) and constructs the lock table accordingly.
> This is described in https://issues.jboss.org/browse/JGRP-2234 (later comments).
> Comment from 2234:
> Clients need to have the following information:
> * Locks they acquired
> * Pending lock requests; locks which they want to acquire but for which they haven't yet received a LOCK_GRANTED response
> * Pending lock release requests; lock that have been released, but for which no RELEASE_LOCK_OK response has been received
> * Ditto for conditions, but we'll tackle them in a second stage
> The reconciliation protocol queues all new requests on the coord and asks all members for their lock information. Once the coord has received this information from all members, it applies this and then drains the queue of pending requests.
> It is important that the requests are ordered per member, ie. a release(L) cannot come before a lock(L).
> Since {{CENTRAL_LOCK}} allows for multiple members to hold the same lock in a split brain scenario, we need to think about how to handle merging where the coord detects that multiple members hold the same lock...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-53) Differences in ORM exception handling in 5.1 vs 5.3
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFWIP-53?page=com.atlassian.jira.plugin.s... ]
Gail Badner commented on WFWIP-53:
----------------------------------
[~simkam], HHH-12666 was fixed in 5.3.3.
Please try running the tests setting {{hibernate.native_exception_handling_51_compliance=true}}, and let us know if anything is still failing due to changes in exception handling.
> Differences in ORM exception handling in 5.1 vs 5.3
> ---------------------------------------------------
>
> Key: WFWIP-53
> URL: https://issues.jboss.org/browse/WFWIP-53
> Project: WildFly WIP
> Issue Type: Bug
> Components: JPA
> Reporter: Martin Simka
> Assignee: Gail Badner
> Priority: Blocker
>
> I see tests failing because {{org.hibernate.hql.internal.ast.QuerySyntaxException}} is wrapped by {{java.lang.IllegalArgumentException}}. I know this has been discussed on hibernate-dev mailing list but without any outcome.
> http://lists.jboss.org/pipermail/hibernate-dev/2018-May/017654.html
> {quote}
> I've been looking at differences in Hibernate exception handling for
> applications that uses "native" (non-JPA) Hibernate when moving from 5.1 to
> 5.3.
> As you know, exception handling changed in 5.2 when hibernate-entitymanager
> was merged into hibernate-core. This change is documented in the 5.2
> migration guide. [1]
> Here is the relevant text:
> "org.hibernate.HibernateException now extends
> javax.persistence.PersistenceExceptions.
> Hibernate methods that "override" methods from their JPA counterparts now
> will also throw various JDK defined RuntimeExceptions (such as
> IllegalArgumentException, IllegalStateException, etc) as required by the
> JPA contract."
> While digging into this, I see that a HibernateException thrown when using
> 5.1 may, in 5.3, be unwrapped, or may be wrapped by a PersistenceException
> (or a subclass), IllegalArgumentException, or IllegalStateException,
> depending on the particular operation being performed when the
> HibernateException is thrown.
> The reason why the exceptions may be wrapped or unwrapped is because
> Hibernate converts exceptions (via
> AbstractSharedSessionContract#exceptionConverter)
> for JPA operations which may wrap the HibernateException or throw a
> different exception. Hibernate does not convert exceptions from strictly
> "native" operations, so those exceptions remain unwrapped.
> Here are a couple of examples to illustrate:
> 1) A HibernateException (org.hibernate.TransientObjectException) was thrown
> in 5.1. In 5.3, the same condition can result in
> org.hibernate.TransientObjectException
> that is either unwrapped, or wrapped by IllegalStateException. I've pushed
> a test to my fork to illustrate. [2]
> Thrown during Session#save, #saveOrUpdate
> In 5.1: org.hibernate.TransientObjectException (unwrapped)
> In 5.3: org.hibernate.TransientObjectException (unwrapped)
> Thrown during Session#persist, #merge, #flush
> In 5.1, org.hibernate.TransientObjectException (unwrapped)
> In 5.3, org.hibernate.TransientObjectException wrapped by
> IllegalStateException
> 2) A HibernateException thrown when using 5.1 may be wrapped by a
> PersistenceException, even though HibernateException already extends
> PersistenceException.
> For example, see TransactionTimeoutTest#testTransactionTimeoutFailure:
> https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/test/java/org/hibernate/test/tm/
> TransactionTimeoutTest.java#L60-L82
> The exception thrown by the test indicates that the transaction timed out.
> This exception is important enough that an application might retry the
> operation, or at least log for future investigation.
> Thrown during Session#persist (or when changed to use Session#merge or
> Session#flush):
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException wrapped by javax.persistence.
> PersistenceException
> Thrown if the test is changed to use Session#save or #saveOrUpdate instead:
> In 5.1: org.hibernate.TransactionException (unwrapped)
> In 5.3: org.hibernate.TransactionException (unwrapped)
> Similarly, by adding some logging, I see that HibernateException objects
> can be wrapped by PersistenceException when running the 5.3 hibernate-core
> unit tests. Depending on the context, I see that some of the following
> exceptions can be wrapped or unwrapped.
> org.hibernate.exception.ConstraintViolationException
> org.hibernate.exception.DataException
> org.hibernate.exception.GenericJDBCException
> org.hibernate.exception.SQLGrammarException
> org.hibernate.id.IdentifierGenerationException
> org.hibernate.loader.custom.NonUniqueDiscoveredSqlAliasException
> org.hibernate.PersistentObjectException
> org.hibernate.PropertyAccessException
> org.hibernate.PropertyValueException
> org.hibernate.TransactionException
> You can see an example using
> org.hibernate.exception.ConstraintViolationException
> at [3].
> In order to deal with these differences, an application could change the
> following (which was appropriate for 5.1):
> try {
> ...
> }
> catch (HibernateException ex) {
> procressHibernateException( ex );
> }
> to the following for 5.3:
> try {
> ...
> }
> catch (PersistenceException | IllegalStateException |
> IllegalArgumentException ex) {
> if ( HibernateException.class.isInstance( ex ) ) {
> handleHibernateException( (HibernateException) ex );
> }
> else if ( HibernateException.class.isInstance( ex.getCause() ) ) {
> handleHibernateException( (HibernateException) ex.getCause() );
> }
> }
> IMO, it's a little clumsy having to deal with both wrapped and unwrapped
> exceptions. It would be better if exceptions were consistently wrapped, or
> consistently unwrapped.
> I haven't had much of a chance to think about how we can deal with this,
> but one thing that comes to mind is to allow an application to choose a
> particular ExceptionConverter implementation. Hibernate would need to be
> changed to always convert exceptions (including for strictly native
> operations) before returning to the application.
> For example, a property, hibernate.exception_converter could be added with
> the following values:
> jpa - default for JPA applications (org.hibernate.internal.
> ExceptionConverterImpl)
> native (or legacy?) - default for native applications that does not wrap
> HibernateException
> fully-qualified class name that implements ExceptionConverter
> If users have to make changes to exception handling for 5.3, do you think
> they would be willing to change their application to use JPA exceptions
> (i.e., hibernate.exception_converter=jpa)?
> Comments?
> Regards,
> Gail
> [1] https://github.com/hibernate/hibernate-orm/blob/5.2/migration-guide.adoc
> [2] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMTransientObjectExceptionUnitTestCase.java
> [3] https://github.com/gbadner/hibernate-core/blob/exception-
> compatibility/orm/hibernate-orm-5/src/test/java/org/hibernate/bugs/
> ORMConstraintViolationExceptionUnitTestCase.java
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2774) Select a data type from the DMN canvas
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2774?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-2774:
--------------------------------
Summary: Select a data type from the DMN canvas (was: Select a data type for a DMN node. )
> Select a data type from the DMN canvas
> ---------------------------------------
>
> Key: DROOLS-2774
> URL: https://issues.jboss.org/browse/DROOLS-2774
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
>
> *Background*
> Persona: here
> Use Cases: As a user I want a means to
> * Add/Create a data type
> * Edit an Existing data type
> * Select a desired data type
> from the canvas view so I can associate it with a DMN node.
> Functional considerations?: Any functional requirements or constraints, such as:
> Does the solution need to leverage any specific existing components (workbench or PF,)...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2774) Select a data type from the DMN canvas
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2774?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-2774:
--------------------------------
Description:
*Background*
Persona: here
Use Cases: As a user I want a means to...
* Add/Create a data type
* Edit an Existing data type
* Select a desired data type ... from the canvas view so I can associate it with a DMN node.
Functional considerations?: Any functional requirements or constraints, such as:
Does the solution need to leverage any specific existing components (workbench or PF,)...
was:
*Background*
Persona: here
Use Cases: As a user I want a means to
* Add/Create a data type
* Edit an Existing data type
* Select a desired data type
from the canvas view so I can associate it with a DMN node.
Functional considerations?: Any functional requirements or constraints, such as:
Does the solution need to leverage any specific existing components (workbench or PF,)...
> Select a data type from the DMN canvas
> ---------------------------------------
>
> Key: DROOLS-2774
> URL: https://issues.jboss.org/browse/DROOLS-2774
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
>
> *Background*
> Persona: here
> Use Cases: As a user I want a means to...
> * Add/Create a data type
> * Edit an Existing data type
> * Select a desired data type ... from the canvas view so I can associate it with a DMN node.
> Functional considerations?: Any functional requirements or constraints, such as:
> Does the solution need to leverage any specific existing components (workbench or PF,)...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2728) UX for custom data-types
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2728?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-2728:
--------------------------------
Epic Name: Data Type UX
> UX for custom data-types
> ------------------------
>
> Key: DROOLS-2728
> URL: https://issues.jboss.org/browse/DROOLS-2728
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2700.png, Screen Shot 2018-07-13 at 11.26.43 AM.png, Screen Shot 2018-07-13 at 11.34.15 AM.png, nested.png, prop-panel.png
>
>
> As a practitioner I want to be able to:
> * select an existing data type
> * create a simple or structured data type
> * create a “compound” (or complex) data type, easily.
> *
expand/collapse views of compound data types, so that I can___
> *
navigate between levels in a compound data type, so that I can___
> * edit an existing data type
> * remove an existing data type
>
…so that I can use the data type when creating a decision related asset.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2774) Select a data type for a DMN node.
by Liz Clayton (JIRA)
Liz Clayton created DROOLS-2774:
-----------------------------------
Summary: Select a data type for a DMN node.
Key: DROOLS-2774
URL: https://issues.jboss.org/browse/DROOLS-2774
Project: Drools
Issue Type: Story
Components: DMN Editor
Reporter: Liz Clayton
Assignee: Liz Clayton
*Background*
Persona: here
Use Cases: As a user I want a means to
* Add/Create a data type
* Edit an Existing data type
* Select a desired data type
from the canvas view so I can associate it with a DMN node.
Functional considerations?: Any functional requirements or constraints, such as:
Does the solution need to leverage any specific existing components (workbench or PF,)...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months