February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1344) Adding a module on remote host doesn't work as expected

by Daniel Kreuter (JIRA)

Daniel Kreuter created WFCORE-1344: -------------------------------------- Summary: Adding a module on remote host doesn't work as expected Key: WFCORE-1344 URL: https://issues.jboss.org/browse/WFCORE-1344 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Daniel Kreuter Assignee: Alexey Loubyansky Hi, I connected to a remote WildFly instance via jboss-cli.bat (from Windows to Linux) and tried to install the MySQL module via {code} module add --name com.mysql --resources=C:\mysql....jar --dependencies=javax.api,javax.transaction.ap {code} What I expected was, that the module would be installed on the remote host. What actually happend was: The CLI installed the module on my local WildFly instance instead. Regards Daniel -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1344) Adding a module on remote host doesn't work as expected

by Daniel Kreuter (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1344?page=com.atlassian.jira.plugi... ] Daniel Kreuter updated WFCORE-1344: ----------------------------------- Description: Hi, I connected to a remote WildFly instance via jboss-cli.bat (from Windows to Linux) and tried to install the MySQL module via {code} module add --name com.mysql --resources=C:\mysql....jar --dependencies=javax.api,javax.transaction.api {code} What I expected was, that the module would be installed on the remote host. What actually happend was: The CLI installed the module on my local WildFly instance instead. Regards Daniel was: Hi, I connected to a remote WildFly instance via jboss-cli.bat (from Windows to Linux) and tried to install the MySQL module via {code} module add --name com.mysql --resources=C:\mysql....jar --dependencies=javax.api,javax.transaction.ap {code} What I expected was, that the module would be installed on the remote host. What actually happend was: The CLI installed the module on my local WildFly instance instead. Regards Daniel > Adding a module on remote host doesn't work as expected > ------------------------------------------------------- > > Key: WFCORE-1344 > URL: https://issues.jboss.org/browse/WFCORE-1344 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Daniel Kreuter > Assignee: Alexey Loubyansky > > Hi, > I connected to a remote WildFly instance via jboss-cli.bat (from Windows to Linux) and tried to install the MySQL module via > {code} > module add --name com.mysql --resources=C:\mysql....jar --dependencies=javax.api,javax.transaction.api > {code} > What I expected was, that the module would be installed on the remote host. What actually happend was: The CLI installed the module on my local WildFly instance instead. > Regards > Daniel -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-418) Update ServerSSLContextBuilder to support chaining of the methods.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-418: ------------------------------------ Summary: Update ServerSSLContextBuilder to support chaining of the methods. Key: ELY-418 URL: https://issues.jboss.org/browse/ELY-418 Project: WildFly Elytron Issue Type: Task Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta4 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1343) Memory leak in host controller

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1343?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1343: ------------------------------------------ Is this different from WFCORE-992? Or is it a request to have the fix applied to the 1.x branch? > Memory leak in host controller > ------------------------------ > > Key: WFCORE-1343 > URL: https://issues.jboss.org/browse/WFCORE-1343 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Final > Reporter: Aparna Chaudhary > Assignee: Brian Stansberry > Priority: Critical > Attachments: WFCORE-992-HC-Leak.PNG > > > The ManagedServerProxy class in host-controller contains a memory leak. The leak can be reproduced by performing multiple requests to HTTP management API. > {noformat} > http://<host>:9990/management/host/host0/server/server0/core-service/platform-mbean/type/memory?include-runtime=true > {noformat} > Applying the fix proposed in WFCORE-992 solves the leak. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1047) Bean introspection is not compatible with Java 8 compiler

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1047: ----------------------------------- Summary: Bean introspection is not compatible with Java 8 compiler Key: DROOLS-1047 URL: https://issues.jboss.org/browse/DROOLS-1047 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco Consider the following 2 interfaces: {code} public interface Base { Object getA(); } public interface Ext extends Base { String getA(); } {code} In Java 7 if you print the declared methods of the Ext interface: System.out.println( Arrays.toString(Ext.class.getDeclaredMethods()) ); you obtain only one method: [public abstract java.lang.String org.drools.compiler.IntrospectionTest$Ext.getA()] This is expected because Class.getDeclaredMethods() "Returns an array containing Method objects reflecting all the declared methods of the class or interface represented by this Class object, including public, protected, default (package) access, and private methods, but excluding inherited methods." https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclare... Nevertheless if I try exactly the same thing in Java 8 I obtain a totally different result: [public abstract java.lang.String org.drools.compiler.IntrospectionTest$Ext1.getA(), public default java.lang.Object org.drools.compiler.IntrospectionTest$Ext1.getA()] Now it is also returning the method declared on the Base interface as it was a default method. This second method is flagged as a bridge method (see here https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getMethod-... ) This change between Java 7 and 8 breaks getter/setter introspection of beans in some specific case -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-417) Update SecurityDomain builders so that build() also is called on the RealmBuilder

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-417: ------------------------------------ Summary: Update SecurityDomain builders so that build() also is called on the RealmBuilder Key: ELY-417 URL: https://issues.jboss.org/browse/ELY-417 Project: WildFly Elytron Issue Type: Task Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta4 Otherwise we can not chain the full definition of the security domain and instead need to hold a reference to the builder just to add the realms. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6106) Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes

by Serg Jakean19019 (JIRA)

[ https://issues.jboss.org/browse/WFLY-6106?page=com.atlassian.jira.plugin.... ] Serg Jakean19019 updated WFLY-6106: ----------------------------------- Priority: Major (was: Optional) > Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes > ------------------------------------------------------------------------------------------- > > Key: WFLY-6106 > URL: https://issues.jboss.org/browse/WFLY-6106 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.1.Final > Reporter: Serg Jakean19019 > Assignee: Paul Ferraro > Attachments: logErrorsInfiniSpan.txt > > > Exception is thrown during access and setting of cache in Infinispan. The error occurs not immediately. > Konfiguration des CacheContainer: > <cache-container name="customCache" default-cache="cachedb"> > <transport lock-timeout="60000"/> > <replicated-cache name="cachedb" mode="SYNC"> > <locking isolation="READ_COMMITTED" striping="false" acquire-timeout="60000" concurrency-level="1000"/> > <transaction mode="BATCH"/> > <expiration lifespan="15000"/> > </replicated-cache> > </cache-container> > Access of cache from Java: > @Resource(lookup = "java:jboss/infinispan/container/customCache") > private CacheContainer cc; > private Map<String, Object> cache; > public void setInInfiniSpan(String name, Object object) { > Cache<Object,Object> cache = cc.getCache(); > TransactionManager tm = cache.getAdvancedCache().getTransactionManager(); > try { > cache.startBatch(); > cache.put(name, object); > cache.endBatch(true); > } catch (SecurityException e) { > // TODO Auto-generated catch block > logger.error("SecurityException: "+e.getMessage(), e); > } catch (IllegalStateException e) { > // TODO Auto-generated catch block > logger.error("IllegalStateException: "+e.getMessage(), e); > } > } > Logs: -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1265) Member can not join cluster after JVM high load

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/JGRP-1265?page=com.atlassian.jira.plugin.... ] kostd kostd commented on JGRP-1265: ----------------------------------- [~belaban], i cannot reproduce in my debug environment too. I have too small heap and too fast heap-dump creation :( But may be my info will be helpful, or you can answer some questions for me about cluster stability increasing: q1. what is a best way to *force* cluster rebuild after dump on coordinator created? If I force sending FIND_INITIAL_MBRS event or FIND_ALL_VIEWS, it would be enough? q2. Usage MERGE3 instead of MERGE2 will increase cluster stability in cases like-this? May be if not only coordinator will initiate new ISPN000094 message q3. may be i need pbcast.STATE_TRANSFER instead RSVP? q4. what other settings i can do to stabilize cluster state during dump creation? any GMS settings for example? > Member can not join cluster after JVM high load > ----------------------------------------------- > > Key: JGRP-1265 > URL: https://issues.jboss.org/browse/JGRP-1265 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.11 > Environment: linux, kernel 2.6.18 > Reporter: Victor N > Assignee: Bela Ban > Fix For: 2.12 > > Attachments: jgroups-tcp.xml > > > In our production system I can see that a node desappers from the cluster if its server was heavily-loaded. It's OK, but the node never comes back to the cluster even after its server is working normally, without load. I can easily reproduce the problem in 2 cases: > 1) by taking a memory dump on the node: jmap -dump:format=b,file=dump.hprof <pid> > Since we have 8-16 GB of RAM, this operation takes much time and blocks JVM - so other members exclude this node from View. > 2) GC (garbage collection) - if JVM is doing GC constantly (and almost can not work) > In both situations the stuck node never reappears in the cluster (even after 1 h). Below are more details. > We have 12 nodes in our cluster, we problematic node is "gate5". > View on gate5: [gate11.mydomain|869] [gate11.mydomain, gate2.mydomain, gate6.mydomain, gate7.mydomain, gate12.mydomain, gate4.mydomain, gate3.mydomain, gate10.mydomain, gate8.mydomain, gate9.mydomain, gate14.mydomain, gate5.mydomain] > View on gate11 (coordinator): [gate11.mydomain|870] [gate11.mydomain, gate2.mydomain, gate6.mydomain, gate7.mydomain, gate12.mydomain, gate4.mydomain, gate3.mydomain, gate10.mydomain, gate8.mydomain, gate9.mydomain, gate14.mydomain] > The coordinator (gate11) is sending GET_MBRS_REQ periodically - I see them in gate5. But I do NOT see response to this request! > All jgroups threads are alive, not dead (I took stack traces). > Another strange thing is that the problematic gate5 sends messages to other nodes and even receives messages from SOME of them! How is it possible - I double-checked that ALL other nodes have view_id=870 (without gate5)? > The only assumption I have is race-conditions which occurs (as always) under high load. > In normal situations such as temporary network failure everything works perfectly - gate5 joins the cluster. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6106) Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes

by Serg Jakean19019 (JIRA)

[ https://issues.jboss.org/browse/WFLY-6106?page=com.atlassian.jira.plugin.... ] Serg Jakean19019 updated WFLY-6106: ----------------------------------- Attachment: logErrorsInfiniSpan.txt > Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes > ------------------------------------------------------------------------------------------- > > Key: WFLY-6106 > URL: https://issues.jboss.org/browse/WFLY-6106 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.1.Final > Reporter: Serg Jakean19019 > Assignee: Paul Ferraro > Priority: Optional > Attachments: logErrorsInfiniSpan.txt > > > Exception is thrown during access and setting of cache in Infinispan. The error occurs not immediately. > Konfiguration des CacheContainer: > <cache-container name="customCache" default-cache="cachedb"> > <transport lock-timeout="60000"/> > <replicated-cache name="cachedb" mode="SYNC"> > <locking isolation="READ_COMMITTED" striping="false" acquire-timeout="60000" concurrency-level="1000"/> > <transaction mode="BATCH"/> > <expiration lifespan="15000"/> > </replicated-cache> > </cache-container> > Access of cache from Java: > @Resource(lookup = "java:jboss/infinispan/container/customCache") > private CacheContainer cc; > private Map<String, Object> cache; > public void setInInfiniSpan(String name, Object object) { > Cache<Object,Object> cache = cc.getCache(); > TransactionManager tm = cache.getAdvancedCache().getTransactionManager(); > try { > cache.startBatch(); > cache.put(name, object); > cache.endBatch(true); > } catch (SecurityException e) { > // TODO Auto-generated catch block > logger.error("SecurityException: "+e.getMessage(), e); > } catch (IllegalStateException e) { > // TODO Auto-generated catch block > logger.error("IllegalStateException: "+e.getMessage(), e); > } > } > Logs: -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6106) Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes

by Serg Jakean19019 (JIRA)

Serg Jakean19019 created WFLY-6106: -------------------------------------- Summary: Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes Key: WFLY-6106 URL: https://issues.jboss.org/browse/WFLY-6106 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 9.0.1.Final Reporter: Serg Jakean19019 Assignee: Paul Ferraro Exception is thrown during access and setting of cache in Infinispan. The error occurs not immediately. Konfiguration des CacheContainer: <cache-container name="customCache" default-cache="cachedb"> <transport lock-timeout="60000"/> <replicated-cache name="cachedb" mode="SYNC"> <locking isolation="READ_COMMITTED" striping="false" acquire-timeout="60000" concurrency-level="1000"/> <transaction mode="BATCH"/> <expiration lifespan="15000"/> </replicated-cache> </cache-container> Access of cache from Java: @Resource(lookup = "java:jboss/infinispan/container/customCache") private CacheContainer cc; private Map<String, Object> cache; public void setInInfiniSpan(String name, Object object) { Cache<Object,Object> cache = cc.getCache(); TransactionManager tm = cache.getAdvancedCache().getTransactionManager(); try { cache.startBatch(); cache.put(name, object); cache.endBatch(true); } catch (SecurityException e) { // TODO Auto-generated catch block logger.error("SecurityException: "+e.getMessage(), e); } catch (IllegalStateException e) { // TODO Auto-generated catch block logger.error("IllegalStateException: "+e.getMessage(), e); } } Logs: -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016