[JBoss JIRA] (WFLY-11128) wsconsume failure on wildfly14 + JDK 11
by mazen mahmoud (Jira)
[ https://issues.jboss.org/browse/WFLY-11128?page=com.atlassian.jira.plugin... ]
mazen mahmoud commented on WFLY-11128:
--------------------------------------
I thought you will deploy the war file (previous attachment) to get the WSDL. Find attached an offline version of the WSDL.
Update the URL as needed. [^HelloWorldService.xml] [^HelloWorldService-imported.xml]
> wsconsume failure on wildfly14 + JDK 11
> ---------------------------------------
>
> Key: WFLY-11128
> URL: https://issues.jboss.org/browse/WFLY-11128
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 14.0.0.Final
> Environment: Windows 7 64bits
> JDK 11
> Wildfly 14
> Reporter: mazen mahmoud
> Assignee: R Searls
> Priority: Major
> Attachments: HelloWorldService-imported.xml, HelloWorldService.xml, demo-service-code.zip, log.txt, logs.zip
>
>
> running wsconsume on a single jax-ws service with JDK 11 failes. (see attached log.txt file)
> the service is very simple.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3089) ThreadSafeTrackableTimeJobFactoryManager for default
by Toshiya Kobayashi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3089?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi reassigned DROOLS-3089:
-----------------------------------------
Assignee: Mario Fusco (was: Maciej Swiderski)
> ThreadSafeTrackableTimeJobFactoryManager for default
> ----------------------------------------------------
>
> Key: DROOLS-3089
> URL: https://issues.jboss.org/browse/DROOLS-3089
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.12.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
>
> By default, TrackableTimeJobFactoryManager is set by SessionConfigurationImpl.
> https://github.com/kiegroup/drools/blob/7.11.0.Final/drools-core/src/main...
> If users access a ksession via multiple threads, it would potentially hit a HashMap concurrency issue (e.g. https://stackoverflow.com/questions/22944918/why-does-the-code-hang-with-...).
> ThreadSafeTrackableTimeJobFactoryManager is bundled for multi-thread use. You can use it by
> Drools 7:
> {noformat}
> System.setProperty("drools.timerJobFactory", "thread_safe_trackable");
> {noformat}
> Drools 6.3+:
> {noformat}
> KieSessionConfiguration kconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> ((org.drools.core.SessionConfiguration)kconf).setTimerJobFactoryType( TimerJobFactoryType.THREAD_SAFE_TRACKABLE );
> KieSession ksession = kContainer.newKieSession("ksession-name", kconf);
> {noformat}
> However, it's better to make ThreadSafeTrackableTimeJobFactoryManager default because "Suddenly hitting an issue in production" is significant than "small overhead by ConcurrentHashMap". (Generally, users are not very conscious about "it is accessed by multi-threads or not")
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3089) ThreadSafeTrackableTimeJobFactoryManager for default
by Toshiya Kobayashi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3089?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi moved JBPM-7836 to DROOLS-3089:
-------------------------------------------------
Project: Drools (was: jBPM)
Key: DROOLS-3089 (was: JBPM-7836)
Component/s: core engine
(was: Runtime Engine)
Affects Version/s: 7.12.0.Final
(was: 7.12.0.Final)
> ThreadSafeTrackableTimeJobFactoryManager for default
> ----------------------------------------------------
>
> Key: DROOLS-3089
> URL: https://issues.jboss.org/browse/DROOLS-3089
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.12.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Maciej Swiderski
> Priority: Major
> Labels: support
>
> By default, TrackableTimeJobFactoryManager is set by SessionConfigurationImpl.
> https://github.com/kiegroup/drools/blob/7.11.0.Final/drools-core/src/main...
> If users access a ksession via multiple threads, it would potentially hit a HashMap concurrency issue (e.g. https://stackoverflow.com/questions/22944918/why-does-the-code-hang-with-...).
> ThreadSafeTrackableTimeJobFactoryManager is bundled for multi-thread use. You can use it by
> Drools 7:
> {noformat}
> System.setProperty("drools.timerJobFactory", "thread_safe_trackable");
> {noformat}
> Drools 6.3+:
> {noformat}
> KieSessionConfiguration kconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> ((org.drools.core.SessionConfiguration)kconf).setTimerJobFactoryType( TimerJobFactoryType.THREAD_SAFE_TRACKABLE );
> KieSession ksession = kContainer.newKieSession("ksession-name", kconf);
> {noformat}
> However, it's better to make ThreadSafeTrackableTimeJobFactoryManager default because "Suddenly hitting an issue in production" is significant than "small overhead by ConcurrentHashMap". (Generally, users are not very conscious about "it is accessed by multi-threads or not")
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11135) Object, instead of a simple boolean should be returned by stop operation on mod_cluster
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11135?page=com.atlassian.jira.plugin... ]
Radoslav Husar edited comment on WFLY-11135 at 10/8/18 6:35 PM:
----------------------------------------------------------------
Actually, the legacy operation (with a fix for WFLY-11117) outputs the legacy format as expected:
{code}
[standalone@localhost:9990 /] /subsystem=modcluster:stop()
{
"outcome" => "success",
"response-headers" => {"warnings" => [{
"warning" => "WFLYCTL0449: Operation stop against the resource at address /subsystem=modcluster is deprecated, and it might be removed in future version. See the the output of the read-operation-description operation to learn more about the deprecation.",
"level" => "WARNING",
"operation" => {
"address" => [("subsystem" => "modcluster")],
"operation" => "stop"
}
}]},
"result" => {"session-draining-complete" => true}
}
{code}
The new format is intentional, the extra wrapping "result" => \{"session-draining-complete" => ... is not necessary and more inline with other operation results.
was (Author: rhusar):
Actually, the legacy operation (with a fix for WFLY-11117) outputs the legacy format as expected:
{code}
[standalone@localhost:9990 /] /subsystem=modcluster:stop()
{
"outcome" => "success",
"response-headers" => {"warnings" => [{
"warning" => "WFLYCTL0449: Operation stop against the resource at address /subsystem=modcluster is deprecated, and it might be removed in future version. See the the output of the read-operation-description operation to learn more about the deprecation.",
"level" => "WARNING",
"operation" => {
"address" => [("subsystem" => "modcluster")],
"operation" => "stop"
}
}]},
"result" => {"session-draining-complete" => true}
}
{code}
The new format is intentional, the wrapping "result" => {"session-draining-complete" => true} is not necessary.
> Object, instead of a simple boolean should be returned by stop operation on mod_cluster
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11135
> URL: https://issues.jboss.org/browse/WFLY-11135
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Minor
>
> When calling {{stop}} operation, object should be returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => {"session-draining-complete" => true}
> }
> {code}
> Instead, just boolean is returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11117) Executing legacy operations in mod_cluster subsystem is not possible with configuration with just one proxy
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11117?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11117:
---------------------------------------
Another part of the problem is the new MSC API, which fails with converted API while the legacy operations still used old MSC API.
> Executing legacy operations in mod_cluster subsystem is not possible with configuration with just one proxy
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11117
> URL: https://issues.jboss.org/browse/WFLY-11117
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Major
>
> Running legacy operation ends up with an error:
> {code}
> [standalone@localhost:9990 /] /subsystem=modcluster/:disable
> {
> "outcome" => "failed",
> "failure-description" => "WFLYMODCLS0022: Legacy operations cannot be used with multiple proxy configurations. Use non-deprecated operations at the correct proxy address.",
> "rolled-back" => true
> }
> {code}
> mod_cluster configuration:
> {code}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-resource
> {
> "outcome" => "success",
> "result" => {
> "mod-cluster-config" => {"configuration" => undefined},
> "proxy" => {"default" => undefined}
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11135) Object, instead of a simple boolean should be returned by stop operation on mod_cluster
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11135?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11135:
---------------------------------------
Actually, the legacy operation (with a fix for WFLY-11117) outputs the legacy format as expected:
{code}
[standalone@localhost:9990 /] /subsystem=modcluster:stop()
{
"outcome" => "success",
"response-headers" => {"warnings" => [{
"warning" => "WFLYCTL0449: Operation stop against the resource at address /subsystem=modcluster is deprecated, and it might be removed in future version. See the the output of the read-operation-description operation to learn more about the deprecation.",
"level" => "WARNING",
"operation" => {
"address" => [("subsystem" => "modcluster")],
"operation" => "stop"
}
}]},
"result" => {"session-draining-complete" => true}
}
{code}
The new format is intentional, the wrapping "result" => {"session-draining-complete" => true} is not necessary.
> Object, instead of a simple boolean should be returned by stop operation on mod_cluster
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11135
> URL: https://issues.jboss.org/browse/WFLY-11135
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Minor
>
> When calling {{stop}} operation, object should be returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => {"session-draining-complete" => true}
> }
> {code}
> Instead, just boolean is returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11135) Object, instead of a simple boolean should be returned by stop operation on mod_cluster
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11135?page=com.atlassian.jira.plugin... ]
Radoslav Husar edited comment on WFLY-11135 at 10/8/18 6:30 PM:
----------------------------------------------------------------
Actually, the legacy operation (with a fix for WFLY-11117) outputs the legacy format as expected:
{code}
[standalone@localhost:9990 /] /subsystem=modcluster:stop()
{
"outcome" => "success",
"response-headers" => {"warnings" => [{
"warning" => "WFLYCTL0449: Operation stop against the resource at address /subsystem=modcluster is deprecated, and it might be removed in future version. See the the output of the read-operation-description operation to learn more about the deprecation.",
"level" => "WARNING",
"operation" => {
"address" => [("subsystem" => "modcluster")],
"operation" => "stop"
}
}]},
"result" => {"session-draining-complete" => true}
}
{code}
The new format is intentional, the wrapping "result" => {"session-draining-complete" => true} is not necessary.
was (Author: rhusar):
Actually, the legacy operation (with a fix for WFLY-11117) outputs the legacy format as expected:
{code}
[standalone@localhost:9990 /] /subsystem=modcluster:stop()
{
"outcome" => "success",
"response-headers" => {"warnings" => [{
"warning" => "WFLYCTL0449: Operation stop against the resource at address /subsystem=modcluster is deprecated, and it might be removed in future version. See the the output of the read-operation-description operation to learn more about the deprecation.",
"level" => "WARNING",
"operation" => {
"address" => [("subsystem" => "modcluster")],
"operation" => "stop"
}
}]},
"result" => {"session-draining-complete" => true}
}
{code}
The new format is intentional, the wrapping "result" => {"session-draining-complete" => true} is not necessary.
> Object, instead of a simple boolean should be returned by stop operation on mod_cluster
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11135
> URL: https://issues.jboss.org/browse/WFLY-11135
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Minor
>
> When calling {{stop}} operation, object should be returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => {"session-draining-complete" => true}
> }
> {code}
> Instead, just boolean is returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11117) Executing legacy operations in mod_cluster subsystem is not possible with configuration with just one proxy
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11117?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-11117:
---------------------------------------
[~jkasik] btw if you want to show the entire subsystem configuration, specify recursive=true, e.g.:
{code}
[standalone@localhost:9990 /] /subsystem=modcluster/:read-resource(recursive=true
{
"outcome" => "success",
"result" => {"proxy" => {"default" => {
"advertise" => true,
"advertise-security-key" => undefined,
"advertise-socket" => "modcluster",
"auto-enable-contexts" => true,
"balancer" => undefined,
"connector" => "ajp",
"excluded-contexts" => undefined,
"flush-packets" => false,
"flush-wait" => -1,
"listener" => "ajp",
"load-balancing-group" => undefined,
"max-attempts" => 1,
"node-timeout" => -1,
"ping" => 10,
"proxies" => undefined,
"proxy-list" => undefined,
"proxy-url" => "/",
"session-draining-strategy" => "DEFAULT",
"simple-load-provider" => undefined,
"smax" => -1,
"socket-timeout" => 20,
"ssl-context" => undefined,
"status-interval" => 10,
"sticky-session" => true,
"sticky-session-force" => false,
"sticky-session-remove" => false,
"stop-context-timeout" => 10,
"ttl" => -1,
"worker-timeout" => -1,
"load-provider" => {"dynamic" => {
"decay" => 2.0,
"history" => 9,
"custom-load-metric" => undefined,
"load-metric" => {"cpu" => {
"capacity" => 1.0,
"property" => undefined,
"type" => "cpu",
"weight" => 1
}}
}},
"ssl" => undefined
}}}
}
{code}
> Executing legacy operations in mod_cluster subsystem is not possible with configuration with just one proxy
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11117
> URL: https://issues.jboss.org/browse/WFLY-11117
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Major
>
> Running legacy operation ends up with an error:
> {code}
> [standalone@localhost:9990 /] /subsystem=modcluster/:disable
> {
> "outcome" => "failed",
> "failure-description" => "WFLYMODCLS0022: Legacy operations cannot be used with multiple proxy configurations. Use non-deprecated operations at the correct proxy address.",
> "rolled-back" => true
> }
> {code}
> mod_cluster configuration:
> {code}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-resource
> {
> "outcome" => "success",
> "result" => {
> "mod-cluster-config" => {"configuration" => undefined},
> "proxy" => {"default" => undefined}
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11127) Can not get activemq and undertow subsystem data from HTTP management api
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11127?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11127:
-----------------------------------------
But it probably won't work anyway once you correct that, since the undertow one doesn't work. I believe this has something to do with 'server' appearing as the key in two elements in the address. I have a vague recollection of some fix related to that kind of thing, although my vague feeling doesn't put the fix in the ~ 6 months since we released WildFly 12. And it's interesting it seems to not be a problem with whatever this management GUI is. Which based on the syntax I assume is the CLI or some other JBoss Remoting based mechanism.
Can you try this with WF 14?
> Can not get activemq and undertow subsystem data from HTTP management api
> -------------------------------------------------------------------------
>
> Key: WFLY-11127
> URL: https://issues.jboss.org/browse/WFLY-11127
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: Toni Moreno
> Assignee: Jeff Mesnil
> Priority: Critical
>
> As described in https://github.com/wildfly/wildfly/issues/11309
> I can not get some subsystems info data with the HTTP management API working with
>
> ======================================
> "product-version" => "12.0.0.Final",
> "product-community-identifier" => "Product",
> "product-home" => "/usr/local/wildfly-12.0.0.Final",
> "standalone-or-domain-identifier" => "HOST_CONTROLLER",
> "host-operating-system" => "Debian GNU/Linux 8 (jessie)}}
> ===============
> This the a activemq POST request with curl and its error
> ---------8<------------------------------------------8<-----------------------
> root@snmpcoldev01:~# curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"host":"master","server":"server-two","subsystem":"messaging-activemq","server":"default"},"operation":"read-children-resources","child-type":"jms-queue","include-runtime":"true","json.pretty":1,"recursive-depth":2}' -u admin
> Enter host password for user 'admin':
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm", nonce="ABCwnAAANoo77ka2vPx9H1LY0IuT5cmkcn5HWBS88gigGzT786K6qnnpMAk=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
> X-Frame-Options: SAMEORIGIN
> Content-Length: 77
> Content-Type: text/html
> Date: Sat, 02 Jun 2018 08:05:53 GMT
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> X-Frame-Options: SAMEORIGIN
> Content-Type: application/json; charset=utf-8
> Content-Length: 103
> Date: Sat, 02 Jun 2018 08:05:53 GMT
> "java.io.IOException: org.jboss.dmr.stream.ModelException: Unexpected content following the DMR
> --------->8------------------------------------------>8-----------------------
> And this the query with the GUI client
> [jboss_jms_queue_gui_query|https://user-images.githubusercontent.com/58834...]
> Also with undertow subsystem
> ---------8<------------------------------------------8<-----------------------
> root@snmpcoldev01:~# curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"address":{"host":"master","server":"server-two","subsystem":"undertow","server":"default-server","http-listener":"default"},"include-runtime":"true","json.pretty":1,"operation":"read-resource","recursive-depth":0}' -u admin
> Enter host password for user 'admin':
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm", nonce="ABC0jwAAN04NaeQD9tlEeeNzizRu5PGuUY9Adi18uuLUzOM1RZNHWkCqnc4=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
> X-Frame-Options: SAMEORIGIN
> Content-Length: 77
> Content-Type: text/html
> Date: Sat, 02 Jun 2018 08:19:54 GMT
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> X-Frame-Options: SAMEORIGIN
> Content-Type: application/json; charset=utf-8
> Content-Length: 302
> Date: Sat, 02 Jun 2018 08:19:54 GMT
> {
> "outcome" : "failed",
> "failure-description" : "WFLYCTL0030: No resource definition is registered for address [\n (\"host\" => \"master\"),\n (\"server\" => \"default-server\"),\n (\"subsystem\" => \"undertow\"),\n (\"http-listener\" => \"default\")\n]",
> "rolled-back" : true
> }
> --------->8------------------------------------------>8-----------------------
> Here Image of the GUI management query.
> [jboss_undertow_listener_gui_query|https://user-images.githubusercontent.c...]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
