[JBoss JIRA] (WFLY-8880) Auth token properties are not applied to legacy AUTH configuration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8880?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-8880:
-------------------------------
Summary: Auth token properties are not applied to legacy AUTH configuration (was: Auth token properties are not applied using legacy AUTH configuration)
> Auth token properties are not applied to legacy AUTH configuration
> ------------------------------------------------------------------
>
> Key: WFLY-8880
> URL: https://issues.jboss.org/browse/WFLY-8880
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> This is related to the discussion that [~lakagwu] started on JBEAP-10285. I reproduced the NPE he was getting, went through the stacktrace, and I think it's a bug.
> {noformat}
> 08:53:37,361 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 67) MSC000001: Failed to start service org.wildfly.clustering.jgroups.channel.ee: org.jboss.msc.service.StartException in service org.wildfly.clustering.jgroups.channel.ee: java.lang.NullPointerException
> at org.jboss.as.clustering.jgroups.subsystem.ChannelBuilder.start(ChannelBuilder.java:104)
> at org.wildfly.clustering.service.AsynchronousServiceBuilder.lambda$start$0(AsynchronousServiceBuilder.java:99)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.NullPointerException
> at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:366)
> at org.jgroups.auth.X509Token.setCertificate(X509Token.java:180)
> at org.jgroups.protocols.AUTH.init(AUTH.java:101)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:861)
> at org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:831)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:108)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelBuilder.start(ChannelBuilder.java:102)
> ... 5 more
> {noformat}
> It looks like the only reason {{ConcurrentClassLoader}} would throw an NPE instead of returning null in {{getResourceAsStream}} is that the name (in this case {{keystore_path}}) is null. That means the {{keystore_path}} is not propagated from EAP configuration to JGroups when the protocol stack is being created.
> The {{getResourceAsStream}} is still expected to fail, as the keystore is not on the classpath, but it should be found after that via the {{FileInputStream}} check that JGroups does.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2908) Per application Expressions driven by the management model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2908?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2908:
-------------------------------------
Component/s: Domain Management
> Per application Expressions driven by the management model
> ----------------------------------------------------------
>
> Key: WFCORE-2908
> URL: https://issues.jboss.org/browse/WFCORE-2908
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Juergen Weber
> Assignee: Jason Greene
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2908) Per application Expressions driven by the management model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2908?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-8883 to WFCORE-2908:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2908 (was: WFLY-8883)
> Per application Expressions driven by the management model
> ----------------------------------------------------------
>
> Key: WFCORE-2908
> URL: https://issues.jboss.org/browse/WFCORE-2908
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Juergen Weber
> Assignee: Jason Greene
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8883) Per application Expressions driven by the management model
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8883:
--------------------------------------
Summary: Per application Expressions driven by the management model
Key: WFLY-8883
URL: https://issues.jboss.org/browse/WFLY-8883
Project: WildFly
Issue Type: Feature Request
Reporter: Juergen Weber
Assignee: Jason Greene
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
${this:aProperty}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
<activation-config-property-value>${this:queuename}</activation-config-property-value>
and define
<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2908) Per application Expressions driven by the management model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2908?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2908:
----------------------------------------
Assignee: (was: Jason Greene)
> Per application Expressions driven by the management model
> ----------------------------------------------------------
>
> Key: WFCORE-2908
> URL: https://issues.jboss.org/browse/WFCORE-2908
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Juergen Weber
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8868) per application Expressions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8868?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8868:
----------------------------------------
[~weberj] Thanks for the input about deployment overlays requiring CLI. That's an oversight in how we developed the feature, not ensuring HAL coverage. Now that [~claudio4j] is aware of it he's filing a JIRA to get that fixed.
In any case, your point about being able to associate properties with the deployment management resource instead of messing around with the deployment content is valid.
I'll clone this into WFCORE. Adding properties to the deployment management resources is something we do in core. But the actual enablement of expression resolution is turned on/off via the ee subsystem in full. So there would be two pieces / two issues. Hence the clone.
> per application Expressions
> ---------------------------
>
> Key: WFLY-8868
> URL: https://issues.jboss.org/browse/WFLY-8868
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Juergen Weber
> Assignee: Jason Greene
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8881) Artemis client uses unbounded thread pool
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8881?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-8881:
------------------------------
Summary: Artemis client uses unbounded thread pool (was: Artemis client uses unbounded threap pool)
> Artemis client uses unbounded thread pool
> -----------------------------------------
>
> Key: WFLY-8881
> URL: https://issues.jboss.org/browse/WFLY-8881
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> Artemis client thread pool can be configured using the messaging-activemq subsystem's global-client-thread-pool-max-size attribute (introduced in 11.0.0.Alpha1).
> By mistake, the default value of this attribute was set to -1 (through the ActiveMQClient.DEFAULT_THREAD_POOL_MAX_SIZE constants).
> This means that unless configured otherwise, the Artemis clients running in the app server (e.g. MDB code) will use an unbounded thread pool.
> The correct configuration is to *not* have a default value. If that's the case, Artemis will determine the size of the pool depending on the number of processors (8 * Runtime.getRuntime().availableProcessors())
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8882) Artemis client uses unbounded threap pool
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-8882:
---------------------------------
Summary: Artemis client uses unbounded threap pool
Key: WFLY-8882
URL: https://issues.jboss.org/browse/WFLY-8882
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 11.0.0.Alpha1
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Priority: Critical
Artemis client thread pool can be configured using the messaging-activemq subsystem's global-client-thread-pool-max-size attribute (introduced in 11.0.0.Alpha1).
By mistake, the default value of this attribute was set to -1 (through the ActiveMQClient.DEFAULT_THREAD_POOL_MAX_SIZE constants).
This means that unless configured otherwise, the Artemis clients running in the app server (e.g. MDB code) will use an unbounded thread pool.
The correct configuration is to *not* have a default value. If that's the case, Artemis will determine the size of the pool depending on the number of processors (8 * Runtime.getRuntime().availableProcessors())
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8632) Add jdbc-network-timeout attribute for messaging JDBC store
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8632?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-8632.
-------------------------------
Fix Version/s: 11.0.0.Beta1
Assignee: Jeff Mesnil (was: Martyn Taylor)
Resolution: Done
> Add jdbc-network-timeout attribute for messaging JDBC store
> -----------------------------------------------------------
>
> Key: WFLY-8632
> URL: https://issues.jboss.org/browse/WFLY-8632
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
> Labels: KK-DR17, eap7.1-rfe-failure
> Fix For: 11.0.0.Beta1
>
>
> If the network goes down between Artemis and DB, the Artemis should behave in the same way as in case that journal storage is used and underlying network file system is disconnected. It should throw an critical IO error and stop itself.
> Currently if network is down, JDBC calls hang until OS tcp timeout expires (typically 10 minutes). It contradicts fail fast pattern.
> This behavior can be changed by setting networkTimeout \[1\] property to non zero value. I think this timeout should be configurable and default value should be less than 30 seconds what is default timeout for client's blocking operations.
> If JDBC connection is closed from any reason (expiration of tcp timeout or networkTimeout), Artemis should throw critical IO error and stop itself.
> Currently even if JDBC connection is closed, Artemis tries to execute DB operations on it what causes throwing of exceptions. Artemis is not able to recover from this state and it must be restarted.
> *Customer impact:* If the network goes down between Artemis and DB, there is no error in server log for 10 minutes. During this time clients are blocked without any explanatory exception. It contradicts fail fast pattern and is difficult to find out what is wrong.
> If JDBC connection is closed after 10 minutes, clients are still successfully connected to Artemis but they get exception for all operations. Since their connections are still active, they don't reconnect to other Artemis instance.
> \[1\] https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setNet...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months