[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node
by Fabian Meyer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ]
Fabian Meyer commented on DROOLS-844:
-------------------------------------
The problem seems to be fixed in the current snapshot (no NPEs after a few test runs).
7.0.0.Beta2 still crashes with a NPE in "org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:728)"
> Crash when node is deleted from query node
> ------------------------------------------
>
> Key: DROOLS-844
> URL: https://issues.jboss.org/browse/DROOLS-844
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final, 7.0.0.Beta1
> Reporter: Fabian Meyer
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 6.4.0.Beta1
>
>
> When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException.
> Exception in thread "Thread-6" java.lang.NullPointerException
> at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176)
> at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360)
> at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331)
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (DROOLS-1350) 401 Unauthorized kie-server rest api peflight call error -> change web.xml security constraints
by Kai Jemella (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1350?page=com.atlassian.jira.plugi... ]
Kai Jemella updated DROOLS-1350:
--------------------------------
Description:
Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :
{code}
zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re...
XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re.... Response for preflight has invalid HTTP status code 401
{code}
CORS Response Header are set, this is not the problem:
{code:xml}
# filter references
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add
# filter
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
(header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")
{code}
The problem occurs by the kie-server web descriptor security constraint:
{code:title=web.xml}
...
<security-constraint>
<web-resource-collection>
<web-resource-name>REST web resources</web-resource-name>
<url-pattern>/services/rest/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>kie-server</role-name>
</auth-constraint>
</security-constraint>
...
{code}
The security constraint should be active for all jax-rs HTTP methods, without the OPTIONS method:
{code:title=web.xml}
...
<security-constraint>
<web-resource-collection>
<web-resource-name>REST web resources</web-resource-name>
<url-pattern>/services/rest/*</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>kie-server</role-name>
</auth-constraint>
</security-constraint>
...
{code}
Tested with firefox and chrome.
was:
Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :
{code}
zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re...
XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re.... Response for preflight has invalid HTTP status code 401
{code}
CORS Response Header are set, this is not the problem:
{code:xml}
# filter references
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add
# filter
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
(header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")
{code}
The problem occurs by the kie-server web descriptor security constraint:
{code:title=web.xml}
...
<security-constraint>
<web-resource-collection>
<web-resource-name>REST web resources</web-resource-name>
<url-pattern>/services/rest/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>kie-server</role-name>
</auth-constraint>
</security-constraint>
...
{code}
The security constraint should be active for all jax-rs HTTP methods, EXPECT the OPTIONS mehtod:
{code:title=web.xml}
...
<security-constraint>
<web-resource-collection>
<web-resource-name>REST web resources</web-resource-name>
<url-pattern>/services/rest/*</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>kie-server</role-name>
</auth-constraint>
</security-constraint>
...
{code}
Tested with firefox and chrome.
> 401 Unauthorized kie-server rest api peflight call error -> change web.xml security constraints
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-1350
> URL: https://issues.jboss.org/browse/DROOLS-1350
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.0.0.Beta2
> Reporter: Kai Jemella
> Assignee: Edson Tirelli
> Attachments: kie-server_cors_preflight_401.png
>
>
> Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :
> {code}
> zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re...
> XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re.... Response for preflight has invalid HTTP status code 401
> {code}
> CORS Response Header are set, this is not the problem:
> {code:xml}
> # filter references
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
> /subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add
> # filter
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
> (header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
> /subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")
> {code}
> The problem occurs by the kie-server web descriptor security constraint:
> {code:title=web.xml}
> ...
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>REST web resources</web-resource-name>
> <url-pattern>/services/rest/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>kie-server</role-name>
> </auth-constraint>
> </security-constraint>
> ...
> {code}
> The security constraint should be active for all jax-rs HTTP methods, without the OPTIONS method:
> {code:title=web.xml}
> ...
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>REST web resources</web-resource-name>
> <url-pattern>/services/rest/*</url-pattern>
> <http-method>GET</http-method>
> <http-method>PUT</http-method>
> <http-method>POST</http-method>
> <http-method>DELETE</http-method>
> </web-resource-collection>
> <auth-constraint>
> <role-name>kie-server</role-name>
> </auth-constraint>
> </security-constraint>
> ...
> {code}
> Tested with firefox and chrome.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (DROOLS-1350) 401 Unauthorized kie-server rest api peflight call error -> change web.xml security constraints
by Kai Jemella (JIRA)
Kai Jemella created DROOLS-1350:
-----------------------------------
Summary: 401 Unauthorized kie-server rest api peflight call error -> change web.xml security constraints
Key: DROOLS-1350
URL: https://issues.jboss.org/browse/DROOLS-1350
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.0.0.Beta2
Reporter: Kai Jemella
Assignee: Edson Tirelli
Attachments: kie-server_cors_preflight_401.png
Using the kie-server REST API with a javascript framework like angular2 results in a [CORS Preflight W3C|https://www.w3.org/TR/cors/#resource-preflight-requests] response 401 :
{code}
zone.js:1274 OPTIONS http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re...
XMLHttpRequest cannot load http://my-kie-server1-default.192.168.42.25.xip.io/kie-server/services/re.... Response for preflight has invalid HTTP status code 401
{code}
CORS Response Header are set, this is not the problem:
{code:xml}
# filter references
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Origin:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Methods:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Headers:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=Access-Control-Allow-Credentials:add
# filter
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Origin:add(header-name=Access-Control-Allow-Origin,header-value="*")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Methods:add(header-name=Access-Control-Allow-Methods,header-value="GET, PUT, POST, OPTIONS, DELETE")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Headers:add \
(header-name=Access-Control-Allow-Headers,header-value="accept, authorization, content-type, x-requested-with, X-KIE-ContentType")
/subsystem=undertow/configuration=filter/response-header=Access-Control-Allow-Credentials:add(header-name=Access-Control-Allow-Credentials,header-value="true")
{code}
The problem occurs by the kie-server web descriptor security constraint:
{code:title=web.xml}
...
<security-constraint>
<web-resource-collection>
<web-resource-name>REST web resources</web-resource-name>
<url-pattern>/services/rest/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>kie-server</role-name>
</auth-constraint>
</security-constraint>
...
{code}
The security constraint should be active for all jax-rs HTTP methods, EXPECT the OPTIONS mehtod:
{code:title=web.xml}
...
<security-constraint>
<web-resource-collection>
<web-resource-name>REST web resources</web-resource-name>
<url-pattern>/services/rest/*</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>kie-server</role-name>
</auth-constraint>
</security-constraint>
...
{code}
Tested with firefox and chrome.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-7418:
-------------------------------------
[~harald.pehl] [~claudio4j] just wanted to ping both of you on this issue as it does affect the console so maybe you guys have some ideas too. Really returning large data sets like this is a problem that the console likely can't do much about, but any ideas you might have would be appreciated.
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by James Perkins (JIRA)
James Perkins created WFLY-7418:
-----------------------------------
Summary: Batch deployments with a large number of executed jobs can lock up or slow down the web console
Key: WFLY-7418
URL: https://issues.jboss.org/browse/WFLY-7418
Project: WildFly
Issue Type: Enhancement
Components: Batch, Web Console
Reporter: James Perkins
Assignee: James Perkins
Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7416) Minimize usage of deprecated PropertiesAttributeDefintion#setXmlName()
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-7416:
---------------------------------
Summary: Minimize usage of deprecated PropertiesAttributeDefintion#setXmlName()
Key: WFLY-7416
URL: https://issues.jboss.org/browse/WFLY-7416
Project: WildFly
Issue Type: Task
Components: Domain Management
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
There are some leftovers in different subsystems that still use setXmlName() to control the properties single element name instead of name of the attribute itself.
For such scenarios custom instance of PropertiesAttributeParser/Marshaller should be created instead
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7417) Minimize usage of deprecated PropertiesAttributeDefintion#setXmlName()
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-7417:
---------------------------------
Summary: Minimize usage of deprecated PropertiesAttributeDefintion#setXmlName()
Key: WFLY-7417
URL: https://issues.jboss.org/browse/WFLY-7417
Project: WildFly
Issue Type: Task
Components: Domain Management
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
There are some leftovers in different subsystems that still use setXmlName() to control the properties single element name instead of name of the attribute itself.
For such scenarios custom instance of PropertiesAttributeParser/Marshaller should be created instead
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on WFLY-6882:
-----------------------------------
In EAP 5 and earlier, this was mostly handled by HA-JNDI. When looking up a singleton in HA-JNDI, you got a non-clustered proxy to whatever node it was deployed on. If it went down, you looked it up again in HA-JNDI and got a proxy to the new singleton.
Does this still work (new lookup of the EJB)?
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months