[JBoss JIRA] (LOGTOOL-109) Create @NotNull or @RequiresNonNull annotation to allow null checks with custom exception
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-109?page=com.atlassian.jira.plugi... ]
James Perkins closed LOGTOOL-109.
---------------------------------
Resolution: Won't Do
I wasn't aware of the wildfly-common assertions.
> Create @NotNull or @RequiresNonNull annotation to allow null checks with custom exception
> -----------------------------------------------------------------------------------------
>
> Key: LOGTOOL-109
> URL: https://issues.jboss.org/browse/LOGTOOL-109
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: James Perkins
>
> Use an {{@NotNull}} or {{@RequiresNonNull}} annotation on a method to generate a {{null}} check and throw, by default, an {{IllegalArgumentException}} if null. Also clean the stack trace.
> {code:java|title=Example Interface}
> @Message(id = 123, value = "Name cannot be null")
> @NotNull(IllegalArgumentException.class)
> void requireNotNull(String name);
> {code}
> {code:java|title=Example Generated Code}
> @Override
> public void requireNotNull(final String name) {
> if (name == null) {
> final IllegalArgumentException result = new IllegalArgumentException(String.format(invalidUser$str(), name));
> final StackTraceElement[] st = result.getStackTrace();
> result.setStackTrace(Arrays.copyOfRange(st, 1, st.length));
> }
> }
> {code}
> The {{@Param}} annotation could be used along with {{@Pos}} for formatting possibly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6686) JGroups ForkChannel can hold references to Hibernate SessionFactoryImpl which cause memory leak
by Mathieu Lachance (JIRA)
Mathieu Lachance created WFLY-6686:
--------------------------------------
Summary: JGroups ForkChannel can hold references to Hibernate SessionFactoryImpl which cause memory leak
Key: WFLY-6686
URL: https://issues.jboss.org/browse/WFLY-6686
Project: WildFly
Issue Type: Bug
Components: Clustering
Environment: Using WF 10 build #2291 (Jun 6, 2016 3:40:44 PM)
https://ci.jboss.org/hudson/job/WildFly-latest-master/2291/changes
Reporter: Mathieu Lachance
Assignee: Paul Ferraro
We are using Hibernate second level cache through JPA configured as such:
{code}
<properties>
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.region.factory_class" value="org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory"/>
</properties>
{code}
After heap dump inspection, it seems that the JGroups ForkChannel identified by "hibernate" can hold a listener that hold the SessionFactoryImpl which then hold the whole application classloader.
When undeploying the application, this can lead to classloader leak.
I took an heap dump of such scenario and analysed it using eclipse memory analyzer (MAT) and here is the result:
{code}
Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
channel org.jgroups.JChannel @ 0xc0eac6a0 | 1 | 112 | 136 | 448
'- channel_listeners java.util.concurrent.CopyOnWriteArraySet @ 0xc0ecd260 | 1 | 16 | 136 | 112
'- al java.util.concurrent.CopyOnWriteArrayList @ 0xc0ecd270 | 1 | 24 | 136 | 96
'- array java.lang.Object[2] @ 0xc0ecd2b8 | 1 | 24 | 136 | 24
'- [0] org.jgroups.fork.ForkChannel @ 0xc103d250 | 1 | 120 | 136 | 1 328
'- channel_listeners java.util.concurrent.CopyOnWriteArraySet @ 0xc103d350 | 1 | 16 | 136 | 968
'- al java.util.concurrent.CopyOnWriteArrayList @ 0xc103d360 | 1 | 24 | 136 | 952
'- array java.lang.Object[1] @ 0xc103d3a8 | 1 | 24 | 136 | 880
'- [0] org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher @ 0xc103d1f0| 1 | 96 | 136 | 856
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{code}
To remove that leak I ugily patched JGroups ForkChannel close method as such:
{code}
/** Closes the fork-channel, essentially setting its state to CLOSED. Note that - contrary to a regular channel -
* a closed fork-channel can be connected again: this means re-attaching the fork-channel to the main-channel*/
@Override
public void close() {
((ForkProtocolStack)prot_stack).remove(fork_channel_id);
if(state == State.CLOSED)
return;
disconnect(); // leave group if connected
prot_stack.destroy();
state=State.CLOSED;
notifyChannelClosed(this);
this.clearChannelListeners(); // <-- this is the line I added
}
{code}
With that change in place, the memory leak is gone. I highly doubt though this is an acceptable fix. Though it does confirm my theory.
I doubt that JGroups is really the culprit -- I'm more in the thinking that the "thing managing" JGroups is the culprit.
Since I'm not an expert around that field I've opened the issue against the Wildfly project. Feel free to move it to the proper project.
If you need any other informations let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-568) NIS Realm
by David Lloyd (JIRA)
David Lloyd created ELY-568:
-------------------------------
Summary: NIS Realm
Key: ELY-568
URL: https://issues.jboss.org/browse/ELY-568
Project: WildFly Elytron
Issue Type: Feature Request
Reporter: David Lloyd
Priority: Optional
It may be useful to users with legacy security systems if Elytron could communicate with an NIS domain for the purposes of authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1584) CLI connect command help content is out of date
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-1584:
-----------------------------------------
Summary: CLI connect command help content is out of date
Key: WFCORE-1584
URL: https://issues.jboss.org/browse/WFCORE-1584
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.0.Alpha1
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
The synopsis states
connect [controller_alias | [protocol://][host][:port]]
while protocol part alone cannot be specified w/o the host.
The other issue is protocol argument is described as
protocol - optional, default value is http.
while the default value is http-remoting.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1583) Enhance a CLI logging
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1583?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky reassigned WFCORE-1583:
-----------------------------------------
Assignee: (was: Alexey Loubyansky)
> Enhance a CLI logging
> ---------------------
>
> Key: WFCORE-1583
> URL: https://issues.jboss.org/browse/WFCORE-1583
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Alexey Loubyansky
> Priority: Minor
>
> We should improve a logging capabilities of CLI. CLI logging is disabled by default, but it can be enabled by altering the jboss-cli-logging.properties.
> Here is my test scenario.
> {noformat}
> [pkremens@localhost bin]$ ./jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo:add(value=bar bar)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] shutdown
> {noformat}
> Set CLI logger level to ALL (logger.org.jboss.as.cli.level=ALL) to see all logs produced by CLI
> actual content of jboss-cli.log - only server response is logged
> {noformat}
> 13:45:48,041 DEBUG [org.jboss.as.cli.CommandContext] connecting to localhost:9990 as null
> 13:46:04,033 INFO [org.jboss.as.cli.CommandContext] {"outcome" => "success"}
> {noformat}
> I can imagine content like following could be helpful for troubleshooting
> {noformat}
> ...
> <TIME> <LEVEL> [org.jboss.as.cli.CommandContext] /system-property=foo:add(value=bar bar)
> {
> "address" => [("system-property" => "foo")],
> "operation" => "add",
> "value" => "barbar"
> }
> <TIME> <LEVEL> [org.jboss.as.cli.CommandContext] {"outcome" => "success"}
> {noformat}
> AFAICT the only possibility to get the actual CLI requests in raw form is to map the content of $HOME/.jboss-cli-history file with configuration history or audit log now.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1583) Enhance a CLI logging
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1583?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky moved JBEAP-4910 to WFCORE-1583:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1583 (was: JBEAP-4910)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Target Release: (was: 7.backlog.GA)
Affects Version/s: (was: 7.0.0.GA)
> Enhance a CLI logging
> ---------------------
>
> Key: WFCORE-1583
> URL: https://issues.jboss.org/browse/WFCORE-1583
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> We should improve a logging capabilities of CLI. CLI logging is disabled by default, but it can be enabled by altering the jboss-cli-logging.properties.
> Here is my test scenario.
> {noformat}
> [pkremens@localhost bin]$ ./jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo:add(value=bar bar)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] shutdown
> {noformat}
> Set CLI logger level to ALL (logger.org.jboss.as.cli.level=ALL) to see all logs produced by CLI
> actual content of jboss-cli.log - only server response is logged
> {noformat}
> 13:45:48,041 DEBUG [org.jboss.as.cli.CommandContext] connecting to localhost:9990 as null
> 13:46:04,033 INFO [org.jboss.as.cli.CommandContext] {"outcome" => "success"}
> {noformat}
> I can imagine content like following could be helpful for troubleshooting
> {noformat}
> ...
> <TIME> <LEVEL> [org.jboss.as.cli.CommandContext] /system-property=foo:add(value=bar bar)
> {
> "address" => [("system-property" => "foo")],
> "operation" => "add",
> "value" => "barbar"
> }
> <TIME> <LEVEL> [org.jboss.as.cli.CommandContext] {"outcome" => "success"}
> {noformat}
> AFAICT the only possibility to get the actual CLI requests in raw form is to map the content of $HOME/.jboss-cli-history file with configuration history or audit log now.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6685) Cache container enable statistics can lead to classloader leak
by Mathieu Lachance (JIRA)
Mathieu Lachance created WFLY-6685:
--------------------------------------
Summary: Cache container enable statistics can lead to classloader leak
Key: WFLY-6685
URL: https://issues.jboss.org/browse/WFLY-6685
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Mathieu Lachance
Assignee: Paul Ferraro
In standalone.xml, if we enable statistics such as:
{code}
<cache-container name="web" default-cache="repl" module="org.wildfly.clustering.web.infinispan" statistics-enabled="true">
<transport lock-timeout="60000"/>
<replicated-cache name="repl" statistics-enabled="true" mode="ASYNC">
<locking isolation="READ_COMMITTED"/>
<transaction locking="OPTIMISTIC" mode="BATCH"/>
<state-transfer chunk-size="512" timeout="240000"/>
</replicated-cache>
</cache-container>
{code}
The following MBean:
{code}
jboss.infinispan:cluster=web,type=channel
{code}
is getting eventually registered when deploying any application.
When undeploying that application, the MBean is not getting unregistered and thus can leak pretty much anything.
Also, if you try to deploy the very same application right after another MBean will get registered:
{code}
jboss.infinispan2:cluster=web,type=channel
{code}
Note: cache enable-statistics=true doesn't seems to leak anything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2078) NPE in Ipv6 Solaris 10 test
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2078?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2078:
--------------------------------
Ah, you mean the NPE in UNICAST3? I have no clue what this is as I don't see a stack trace.
If you want me to look into this, you have to change the UNICAST3 protocol [1] and print the stack trace, so I know what's causing the NPE.
Is this reproduceable?
[1] https://github.com/belaban/JGroups/blob/3.6/src/org/jgroups/protocols/UNI...
> NPE in Ipv6 Solaris 10 test
> ---------------------------
>
> Key: JGRP-2078
> URL: https://issues.jboss.org/browse/JGRP-2078
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Bogdan Sikora
> Assignee: Bela Ban
>
> {noformat}
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000079: Channel server local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel hibernate local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079: Channel web local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> {noformat}
> {noformat}
> 2016-06-08 05:50:01,589 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 69) WFLYCLINF0002: Started clusterbench.war cache from web container
> 2016-06-08 05:50:01,625 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started routing cache from web container
> 2016-06-08 05:50:02,894 ERROR [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> 2016-06-08 05:50:03,379 ERROR [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> 2016-06-08 05:50:03,878 ERROR [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> ...
> {noformat}
> https://paste.fedoraproject.org/376166/65389534/
> Config
> https://paste.fedoraproject.org/376150/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2078) NPE in Ipv6 Solaris 10 test
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2078?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2078:
--------------------------------
This is still Infinispan...
> NPE in Ipv6 Solaris 10 test
> ---------------------------
>
> Key: JGRP-2078
> URL: https://issues.jboss.org/browse/JGRP-2078
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Bogdan Sikora
> Assignee: Bela Ban
>
> {noformat}
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000079: Channel server local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel hibernate local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079: Channel web local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> {noformat}
> {noformat}
> 2016-06-08 05:50:01,589 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 69) WFLYCLINF0002: Started clusterbench.war cache from web container
> 2016-06-08 05:50:01,625 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started routing cache from web container
> 2016-06-08 05:50:02,894 ERROR [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> 2016-06-08 05:50:03,379 ERROR [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> 2016-06-08 05:50:03,878 ERROR [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> ...
> {noformat}
> https://paste.fedoraproject.org/376166/65389534/
> Config
> https://paste.fedoraproject.org/376150/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months