[JBoss JIRA] (AS7-4068) Failed to parse configuration with standalone-ha.xml
by Michal Babacek (JIRA)
Michal Babacek created AS7-4068:
-----------------------------------
Summary: Failed to parse configuration with standalone-ha.xml
Key: AS7-4068
URL: https://issues.jboss.org/browse/AS7-4068
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Reporter: Michal Babacek
Assignee: Michal Babacek
I find rather unfortunate that the current master, JBoss AS 7.1.1.Final-SNAPSHOT *4a60df3*, brings this config in standalone-ha.xml:
{code:lang=xml}
<?xml version='1.0' encoding='UTF-8'?>
<server xmlns="urn:jboss:domain:1.2">
<extensions>
+++
{code}
brings this on startup:
{code}
[JBoss] =========================================================================
[JBoss]
[JBoss] JBoss Bootstrap Environment
[JBoss]
[JBoss] JBOSS_HOME: /tmp/hudson/jboss-as-7.1.1.Final-SNAPSHOT
[JBoss]
[JBoss] JAVA: /qa/tools/opt/amd64/jdk1.6.0_last/bin/java
[JBoss]
[JBoss] JAVA_OPTS: -XX:+UseCompressedOops -XX:+TieredCompilation -Dprogram.name=standalone.sh -server -Xms1303m -Xmx1303m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.lang.ClassLoader.allowArraySyntax=true -Djava.net.preferIPv4Stack=true -Djboss.messaging.ServerPeerID=0 -Dsf.pid=54OfFAZ9j3Wzmnj5
[JBoss]
[JBoss] =========================================================================
[JBoss]
[JBoss] 04:07:59,464 INFO [org.jboss.modules] JBoss Modules version 1.1.1.GA
[JBoss] 04:07:59,729 INFO [org.jboss.msc] JBoss MSC version 1.0.2.GA
[JBoss] 04:07:59,786 INFO [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" starting
[JBoss] 04:08:00,187 ERROR [org.jboss.as.controller] JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
[JBoss] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:161) [jboss-as-controller-7.1.1.Final-SNAPSHOT.jar:7.1.1.Final-SNAPSHOT]
[JBoss] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
[JBoss] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
[JBoss] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125) [jboss-as-controller-7.1.1.Final-SNAPSHOT.jar:7.1.1.Final-SNAPSHOT]
[JBoss] at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:187) [jboss-as-controller-7.1.1.Final-SNAPSHOT.jar:7.1.1.Final-SNAPSHOT]
[JBoss] at org.jboss.as.server.ServerService.boot(ServerService.java:261) [jboss-as-server-7.1.1.Final-SNAPSHOT.jar:7.1.1.Final-SNAPSHOT]
[JBoss] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.1.Final-SNAPSHOT.jar:7.1.1.Final-SNAPSHOT]
[JBoss] ... 1 more
[JBoss] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
[JBoss] Message: Unexpected element '{urn:jboss:domain:1.2}server'
[JBoss] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
[JBoss] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
[JBoss] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:117) [jboss-as-controller-7.1.1.Final-SNAPSHOT.jar:7.1.1.Final-SNAPSHOT]
[JBoss] ... 4 more
[JBoss]
[JBoss] 04:08:00,195 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" stopped in 10ms
{code},
note:
*ParseError at [row,col]:[3,1] [JBoss] Message: Unexpected element '{urn:jboss:domain:1.2}server'*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4036) JCA subsystem doesn't unregister <short-running-threads> and <long-running-threads> workmanager subelements after removing
by Vladimir Rastseluev (JIRA)
Vladimir Rastseluev created AS7-4036:
----------------------------------------
Summary: JCA subsystem doesn't unregister <short-running-threads> and <long-running-threads> workmanager subelements after removing
Key: AS7-4036
URL: https://issues.jboss.org/browse/AS7-4036
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.1.0.Final
Reporter: Vladimir Rastseluev
Assignee: Stefano Maestri
Fix For: 7.1.1.Final
[standalone@localhost:9999 /] /subsystem=jca/workmanager=newWM:add(name=newWM)
{
"outcome" => "success",
"response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" }
}
[standalone@localhost:9999 /] /subsystem=jca/workmanager=newWM/short-running-threads=newWM:add(name=newWm,core-threads=20,max-threads=20,queue-length=20)
{
"outcome" => "success",
"response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9999 /] /subsystem=jca/workmanager=newWM:remove
{
"outcome" => "success",
"response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } }
}
[standalone@localhost:9999 /] /subsystem=jca/workmanager=newWM:add(name=newWM)
{
"outcome" => "success",
"response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" }
}
[standalone@localhost:9999 /] /subsystem=jca/workmanager=newWM/short-running-threads=newWM:add(name=newWm,core-threads=20,max-threads=20,queue-length=20)
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: Service jboss.thread.executor.newWM.thread-factory is already registered",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3128) Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3128?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-3128:
-----------------------------------
And again:
https://hudson.qa.jboss.com/hudson/view/ESSC/job/AS7-TS-valid-all-debug/l...
> Arquillian should wait until a port is free after AS JVM process ends to prevent "port in use".
> -----------------------------------------------------------------------------------------------
>
> Key: AS7-3128
> URL: https://issues.jboss.org/browse/AS7-3128
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.0.CR1
> Reporter: Ondrej Zizka
> Assignee: Andrew Rubinger
> Priority: Blocker
> Labels: arq_qe_blocker
> Fix For: 7.1.2.Final
>
>
> (05:54:09) dmlloyd: when running with JDWP enabled on the client or server, I occasionally get bind exceptions due to address in use
> (05:54:25) dmlloyd: which means that tests are running into each other without waiting for termination of the previous one
> (05:54:35) dmlloyd: which may also be causing other issues
> (05:56:04) ozizka: dmlloyd: Yes, lbarrerio observed similar problem too,
> (05:56:47) ozizka: And that's arq's issue too - there's no way to get around this currently AFAIK. Or is there?
> (05:57:05) ozizka: Perhaps "manually" wait in @AfterClass or such
> (05:57:07) dmlloyd: yeah, it can wait for the child process to terminate
> (05:57:07) ozizka: which is ugly
> (05:57:14) dmlloyd: I mean arq should
> (05:59:17) ozizka: dmlloyd: Do you have it somewhere on hudson?
> (05:59:24) ozizka: dmlloyd: It never happened to me actually
> (05:59:49) ozizka: Send me a log if you have one handy
> (06:01:35) dmlloyd: ozizka: no, try running with this command though:
> {code}
> mvn -DallTests install -Djpda -Dsurefire.jpda.args=-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n \
> -Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"
> {code}
> (06:13:56) ozizka: dmlloyd: That's on linux?
> (06:14:03) dmlloyd: yes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (JGRP-1427) Race conditions during TCP start up cause broken connections and cluster-wide slow down
by Jay Guidos (JIRA)
Jay Guidos created JGRP-1427:
--------------------------------
Summary: Race conditions during TCP start up cause broken connections and cluster-wide slow down
Key: JGRP-1427
URL: https://issues.jboss.org/browse/JGRP-1427
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.5
Reporter: Jay Guidos
Assignee: Bela Ban
I actually found this on 2.4.1, but I can reproduce it on the Git master.
When starting our cluster of 18 nodes using TCP, perhaps one start in 20 results in a node having very slow cluster response. Some trace logging eventually revealed that on random occasions one of the TCP connections to a sister node would start and then immediate terminate. From that point on, every cluster broadcast would be subject to the response timeout (for us it was at 60 seconds).
The problem is in org.jgroups.blocks.BasicConnectionTable. There is a number of non-threadsafe field reference updates during startup, but in particular in BasicConnectionTable.Sender.start() the 'senderThread' field is updated in one thread, and immediately referenced in the daughter thread's invocation of BasicConnectionTable.Sender.run().
If the timing works out wrong, 'senderThread' is set in the L2 cache of the PingSender thread, but not yet updated in the L2 cache used by ConnectionTable.Connection.Sender, and hence the run() method exits immediately. Here is the smoking gun from a trace log:
{noformat}
22:18:22,985 INFO [org.jgroups.blocks.ConnectionTable] {main} server socket created on 127.0.0.1:7800
22:18:22,997 DEBUG [org.jgroups.blocks.MessageDispatcher$ProtocolAdapter] {main} setting local_addr (null) to 127.0.0.1:7800
22:18:23,013 DEBUG [org.jgroups.blocks.ConnectionTable] {PingSender} ConnectionTable.Connection.Receiver started
22:18:23,013 INFO [org.jgroups.blocks.ConnectionTable] {PingSender} created socket to 127.0.0.1:7801
22:18:23,015 DEBUG [org.jgroups.blocks.ConnectionTable] {PingSender} ConnectionTable.Connection.Sender thread started
22:18:23,018 DEBUG [org.jgroups.blocks.ConnectionTable] {PingSender} ConnectionTable.Connection.Receiver started
22:18:23,018 INFO [org.jgroups.blocks.ConnectionTable] {PingSender} created socket to 127.0.0.1:7802
22:18:23,018 DEBUG [org.jgroups.blocks.ConnectionTable] {ConnectionTable.Connection.Sender [127.0.0.1:44710 - 127.0.0.1:7802]} ConnectionTable.Connection.Sender thread terminated
22:18:23,018 DEBUG [org.jgroups.blocks.ConnectionTable] {PingSender} ConnectionTable.Connection.Sender thread started
22:18:23,019 DEBUG [org.jgroups.blocks.ConnectionTable] {PingSender} ConnectionTable.Connection.Receiver started
2
{noformat}
You can see that at 22:18:23,018 the PingSender thread created a Sender, and in the same millisecond the ConnectionTable.Connection.Sender thread killed it off.
The fix is easy, just convert 'senderThread' to an AtomicReference. This is very old code, I am not sure why we were the first ones to report this? Perhaps it is because our application is heavily multithreaded and we run on servers with 16 physical CPU cores. There is a very high chance that PingSender and ConnectionTable.Connection.Sender were not bound to the same core, and hence their L2 caches had significant time intervals where they were out of sync. There were a number of other sloppy references and updates to variables that were used for thread control in BasicConnectionTable, I think this code could benefit from a review for that kind of thing.
Cheers!
Jay Guidos
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (JGRP-1435) Out-by-one errors in port_range handling
by David Hotham (JIRA)
David Hotham created JGRP-1435:
----------------------------------
Summary: Out-by-one errors in port_range handling
Key: JGRP-1435
URL: https://issues.jboss.org/browse/JGRP-1435
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.6, 3.1
Reporter: David Hotham
Assignee: Bela Ban
Priority: Minor
Various mismatches between documentation and code for port_range handling. I don't know which you prefer to fix. It would also be desirable if the behaviour was consistent between different protocols.
BPING says
@Property(description="Sends discovery packets to ports 8555 to (8555+port_range)")
but the code goes
for(int i=bind_port; i < bind_port+port_range; i++) {
so actually packets go to 8555+port_range-1, and value 0 is meaningless. Probably that should be a <= there (with corresponding fixes required in a couple of other places in the file).
FD_SOCK says
@Property(description="Number of ports to probe for start_port and client_bind_port")
but in setupPingSocket(), the code goes
if(num_bind_attempts++ > port_range) {
Since this is a post-increment, we'll actually try not one but two more ports than promised. Eg if port_range is zero, we'll try both client_bind_port and client_bind_port+1. Probably you want to change this to a pre-increment, and also change the documentation to describe what actually happens.
I believe that TCPPING and TP both behave as advertised, ie:
@Property(description="The range of valid ports, from bind_port to end_port. 0 only binds to bind_port and fails if taken")
... and my suggestion would be that this is what you really want in all cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (JGRP-1431) GossipRouter drops members from the routing table
by Guy Golan (JIRA)
Guy Golan created JGRP-1431:
-------------------------------
Summary: GossipRouter drops members from the routing table
Key: JGRP-1431
URL: https://issues.jboss.org/browse/JGRP-1431
Project: JGroups
Issue Type: Bug
Affects Versions: 3.1
Reporter: Guy Golan
Assignee: Bela Ban
I have looked at GossipRouter.java and it seems like it has a bug that sometimes drops new members from the routing table.
The problem is caused by the methods: "removeEntry" and "handleConnect".
Specifically, the method "removeEntry" contains the following code fragment:
if(map.isEmpty()) {
routingTable.remove(group);
So, if "removeEntry" is executed and a concurrent "handleConnect" adds a member (to the same group) between "map.isEmpty()" and "routingTable.remove(group)" then this member will be dropped from the routing-table.
Note that, in this case the method "handleConnect" still sends "CONNECT_OK" to the client.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month