[JBoss JIRA] (JASSIST-245) Javassist 3.19.0-GA causes compilation warnings with -Xlint:classfile
by wuwen wuwen (JIRA)
[ https://issues.jboss.org/browse/JASSIST-245?page=com.atlassian.jira.plugi... ]
wuwen wuwen edited comment on JASSIST-245 at 11/9/15 8:40 PM:
--------------------------------------------------------------
{code}<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<testSource>1.8</testSource>
<testTarget>1.8</testTarget>
<compilerArgument>-parameters</compilerArgument>
</configuration>
</plugin>{code}
maybe that's the reason ?
[pr-54|https://github.com/jboss-javassist/javassist/pull/54]
was (Author: wuwen5):
{code}<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<testSource>1.8</testSource>
<testTarget>1.8</testTarget>
<compilerArgument>-parameters</compilerArgument>
</configuration>
</plugin>{code}
maybe that's the reason ?
> Javassist 3.19.0-GA causes compilation warnings with -Xlint:classfile
> ---------------------------------------------------------------------
>
> Key: JASSIST-245
> URL: https://issues.jboss.org/browse/JASSIST-245
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.19.0-GA
> Reporter: David Carr
> Assignee: Shigeru Chiba
>
> Tested using Oracle Java 1.8.0_40.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by Stefan Dilk (JIRA)
Stefan Dilk created WFCORE-1119:
-----------------------------------
Summary: ManagedDatagramSocketBinding throw NPE
Key: WFCORE-1119
URL: https://issues.jboss.org/browse/WFCORE-1119
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 2.0.0.CR8
Reporter: Stefan Dilk
Assignee: Jason Greene
i think i have found the same bug as in WFCORE-1033 but in another method.
in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
{noformat}
[Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
java.lang.NullPointerException
[Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
6)
[Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
[Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
[Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
[Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
[Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
[Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
[Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
[Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
[Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
[Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
[Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
[Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
[Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
[Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
[Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
[Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
[Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
[Server:mgmt-1-prod] ... 5 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5652) Datasource spy attribute has no effect
by Rich DiCroce (JIRA)
Rich DiCroce created WFLY-5652:
----------------------------------
Summary: Datasource spy attribute has no effect
Key: WFLY-5652
URL: https://issues.jboss.org/browse/WFLY-5652
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.CR2
Reporter: Rich DiCroce
Assignee: Jason Greene
The spy attribute of a datasource does not appear to have any effect. The datasources XSD says to set spy to true and enable the org.jboss.jdbc log category, but I did that and got no debug info in my log. From a quick search of the WildFly and IronJacamar codebases, it looks like no meaningful code ever checks the value of the spy attribute.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-738) Add clear cache operation on cache container and cache (accessible via admin console)
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-738?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro closed WFLY-738.
-----------------------------
Resolution: Won't Do
I'm rejecting this for a couple reasons:
# Such an operation is only generally safe for an invalidation cache.
# Such an operation would need RBAC.
# Clear is not an atomic operation in Infinispan, so this is an unsafe operation to begin with.
# The primary invalidation cache use case in WildFly is Hibernate's RegionFactory, which already has a clear operation.
> Add clear cache operation on cache container and cache (accessible via admin console)
> -------------------------------------------------------------------------------------
>
> Key: WFLY-738
> URL: https://issues.jboss.org/browse/WFLY-738
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Guillaume Grossetie
> Assignee: Paul Ferraro
> Fix For: Awaiting Volunteers
>
>
> Add operation on infinispan subsystem to clear cache at cache container level (ie. clear all caches for the container) and at cache level.
> The implementation of the clear operation just calls the method #clear() on the org.infinispan.Cache interface. If needed we can clear the associated CacheStore (make it optional ?) and handle more complex cases.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5651) Validation errors in "jboss-web_10_0.xsd"
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-5651?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf commented on WFLY-5651:
--------------------------------------
Seems to be the same issue, with some more problems added...
> Validation errors in "jboss-web_10_0.xsd"
> -----------------------------------------
>
> Key: WFLY-5651
> URL: https://issues.jboss.org/browse/WFLY-5651
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.CR4
> Reporter: Wolfgang Knauf
> Assignee: Jason Greene
> Attachments: jboss-common_10_0.xsd, jboss-web_10_0.xsd, validationerrors.png
>
>
> When creating an instance of this XSD file, Eclipse cannot validate the XSD file.
> Attached is a screenshot of all errors. Sorry for the screenshot, but Eclipse does not allow copying of error messages from the "validation errors in included xsd file" window.
> I assume the errors are caused mainly by this problem:
> a) "jboss-web_10_0.xsd" declares the namespace "xmlns:jboss="http://www.jboss.com/xml/ns/javaee" ", but it does not include/import any file where those common things are declared. I assume it references "jboss-common_6_0.xsd"? See "jboss-web_7_0.xsd", where the common file is included.
> b) if this is true, the next problem is that there is a namespace mismatch: jboss-common_6_0.xsd declares this: xmlns:javaee="http://java.sun.com/xml/ns/javaee"
> But "jboss-web_10_0.xsd" declares xmlns:javaee="http://xmlns.jcp.org/xml/ns/javaee"
> Probably it should be the same namespace in both files?
> So a new "jboss-common_10_0.xsd" would be needed, which also imports "javaee_7.xsd" instead of "javaee_6.xsd".
> Attached are "jboss-web_10_0.xsd" and "jboss-common_10_0.xsd" files which don't contain the namespace mismatch errors any more. But I don't know whether they are correct and would work when wildfly validates a xml file with this schema.
> My files still contain one last error (don't know how to fix it):
> src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'boolean' satisfies none of these conditions.
> in jboss-web_10_0.xsd, line 313
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5651) Validation errors in "jboss-web_10_0.xsd"
by Wolfgang Knauf (JIRA)
Wolfgang Knauf created WFLY-5651:
------------------------------------
Summary: Validation errors in "jboss-web_10_0.xsd"
Key: WFLY-5651
URL: https://issues.jboss.org/browse/WFLY-5651
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 10.0.0.CR4
Reporter: Wolfgang Knauf
Assignee: Jason Greene
Attachments: jboss-common_10_0.xsd, jboss-web_10_0.xsd, validationerrors.png
When creating an instance of this XSD file, Eclipse cannot validate the XSD file.
Attached is a screenshot of all errors. Sorry for the screenshot, but Eclipse does not allow copying of error messages from the "validation errors in included xsd file" window.
I assume the errors are caused mainly by this problem:
a) "jboss-web_10_0.xsd" declares the namespace "xmlns:jboss="http://www.jboss.com/xml/ns/javaee" ", but it does not include/import any file where those common things are declared. I assume it references "jboss-common_6_0.xsd"? See "jboss-web_7_0.xsd", where the common file is included.
b) if this is true, the next problem is that there is a namespace mismatch: jboss-common_6_0.xsd declares this: xmlns:javaee="http://java.sun.com/xml/ns/javaee"
But "jboss-web_10_0.xsd" declares xmlns:javaee="http://xmlns.jcp.org/xml/ns/javaee"
Probably it should be the same namespace in both files?
So a new "jboss-common_10_0.xsd" would be needed, which also imports "javaee_7.xsd" instead of "javaee_6.xsd".
Attached are "jboss-web_10_0.xsd" and "jboss-common_10_0.xsd" files which don't contain the namespace mismatch errors any more. But I don't know whether they are correct and would work when wildfly validates a xml file with this schema.
My files still contain one last error (don't know how to fix it):
src-ct.2.1: Complex Type Definition Representation Error for type 'symbolic-linked-allowedType'. When <simpleContent> is used, the base type must be a complexType whose content type is simple, or, only if restriction is specified, a complex type with mixed content and emptiable particle, or, only if extension is specified, a simple type. 'boolean' satisfies none of these conditions.
in jboss-web_10_0.xsd, line 313
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5212) IllegalStateException: no transaction associated with thread after undeploy
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5212?page=com.atlassian.jira.plugin.... ]
Paul Ferraro resolved WFLY-5212.
--------------------------------
Fix Version/s: 10.0.0.Final
Resolution: Done
Fixed by https://github.com/wildfly/wildfly/commit/247a6f8707509967b778eeb9ede43df...
> IllegalStateException: no transaction associated with thread after undeploy
> ---------------------------------------------------------------------------
>
> Key: WFLY-5212
> URL: https://issues.jboss.org/browse/WFLY-5212
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 10.0.0.Final
>
>
> Intermittent failure, so far seen in only this scenario:
> ejb-ejbservlet-undeploy-dist-sync
> Setup: 4 node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> Right after undeploying the application servers perf19,20,21 logged this error approx. 50 times:
> {code}
> [JBossINF] [0m[31m18:37:43,800 ERROR [io.undertow.request] (default task-111) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.IllegalStateException: no transaction associated with thread
> [JBossINF] at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:94)
> [JBossINF] at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.discard(ActiveTransactionBatch.java:57)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:131)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5135) Infinispan cluster topology rebalance
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5135?page=com.atlassian.jira.plugin.... ]
Paul Ferraro resolved WFLY-5135.
--------------------------------
Fix Version/s: 10.0.0.CR3
Resolution: Done
Fixed by https://github.com/wildfly/wildfly/commit/25e62d6c854fb567aa743f3828ef34b...
> Infinispan cluster topology rebalance
> -------------------------------------
>
> Key: WFLY-5135
> URL: https://issues.jboss.org/browse/WFLY-5135
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Environment: CentOS 7, Java 8u51, Wildfly 9.0.1.Final, TCP/TCPPING cluster
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR3
>
>
> Configured TCPPING based TCP transport:
> {code}
> <stack name="tcpping">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="TCPPING">
> <property name="port_range">0</property>
> <property name="initial_hosts">...</property>
> </protocol>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="BARRIER"/>
> <protocol type="pbcast.NAKACK"/>
> <protocol type="UNICAST2"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS">
> <property name="join_timeout">3000</property>
> </protocol>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> {code}
> The cluster works but after some node restart, one of the node try to acquire the coordinator role and fail (the previous coordinator was the dc02-wild01):
> {code}
> 2015-08-19 10:00:41,597 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-16,ee,dc01-wild01) ISPN000094: Received new cluster view for channel gacivsContainer: [dc02-wild02|13] (4) [dc02-wild02, dc01-wild01, dc01-wild02, dc02-wild01]
> 2015-08-19 10:00:41,598 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-16,ee,dc01-wild01) ISPN000094: Received new cluster view for channel web: [dc02-wild02|13] (4) [dc02-wild02, dc01-wild01, dc01-wild02, dc02-wild01]
> 2015-08-19 10:00:41,598 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-16,ee,dc01-wild01) ISPN000094: Received new cluster view for channel ejb: [dc02-wild02|13] (4) [dc02-wild02, dc01-wild01, dc01-wild02, dc02-wild01]
> 2015-08-19 10:00:46,448 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,ee,dc01-wild01) ISPN000093: Received new, MERGED cluster view for channel gacivsContainer: MergeView::[dc01-wild01|14] (4) [dc01-wild01, dc02-wild01, dc01-wild02, dc02-wild02], 2 subgroups: [dc02-wild02|12] (3) [dc02-wild02, dc01-wild01, dc01-wild02], [dc02-wild02|13] (4) [dc02-wild02, dc01-wild01, dc01-wild02, dc02-wild01]
> 2015-08-19 10:00:46,450 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,ee,dc01-wild01) ISPN000093: Received new, MERGED cluster view for channel web: MergeView::[dc01-wild01|14] (4) [dc01-wild01, dc02-wild01, dc01-wild02, dc02-wild02], 2 subgroups: [dc02-wild02|12] (3) [dc02-wild02, dc01-wild01, dc01-wild02], [dc02-wild02|13] (4) [dc02-wild02, dc01-wild01, dc01-wild02, dc02-wild01]
> 2015-08-19 10:00:46,450 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,ee,dc01-wild01) ISPN000093: Received new, MERGED cluster view for channel ejb: MergeView::[dc01-wild01|14] (4) [dc01-wild01, dc02-wild01, dc01-wild02, dc02-wild02], 2 subgroups: [dc02-wild02|12] (3) [dc02-wild02, dc01-wild01, dc01-wild02], [dc02-wild02|13] (4) [dc02-wild02, dc01-wild01, dc01-wild02, dc02-wild01]
> 2015-08-19 10:00:46,637 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p4-t8) ISPN000196: Failed to recover cluster state after the current node became the coordinator: org.infinispan.commons.CacheException: Unsuccessful response received from node dc02-wild01: CacheNotFoundResponse
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:482)
> at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:350)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:286)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:590)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:745)
> {code}
> And the cluster gone...
> {code}
> 2015-08-19 10:10:17,312 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p5-t49) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 10 seconds for key 113481734232139653919 and requestor GlobalTransaction:<dc01-wild01>:628:remote. Lock is held by GlobalTransaction:<dc01-wild01>:602:remote, while request came from dc01-wild01
> [...]
> 2015-08-19 10:13:32,295 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,dc01-wild01) JGRP000032: dc01-wild01: no physical address for dc02-wild01, dropping message
> [...]
> 2015-08-19 10:11:32,707 WARN [org.infinispan.transaction.impl.TransactionTable] (TxCleanupService,dist,dc01-wild02) ISPN000326: Remote transaction GlobalTransaction:<dc02-wild02>:1240:remote timed out. Rolling back after 84623 ms
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months