January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6390) Problem with jboss versions of xerces and xalan: XML Parsing Error: duplicate attribute in wsdl definitions

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6390?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6390: ---------------------------------- Component/s: Web Services > Problem with jboss versions of xerces and xalan: XML Parsing Error: duplicate attribute in wsdl definitions > ----------------------------------------------------------------------------------------------------------- > > Key: AS7-6390 > URL: https://issues.jboss.org/browse/AS7-6390 > Project: Application Server 7 > Issue Type: Bug > Components: Web Services > Affects Versions: 7.1.1.Final > Reporter: Michael Vetter > > We are using a feature (SimpleWsdl11Definition) of spring ws (version 1.5.9) to serve wsdl files to the browser or to a client. > Our wsdl file has custom namespace prefixes like this: > <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:bsf="http:/... > > It works in JBoss 5.1 and eap 6.0.0 but with JBoss 7.1.1 or the current 7.2 snapshot I get the following error when I enter the wsdl URL in the browser: > XML Parsing Error: duplicate attribute > Location: http://localhost:8080/sc-webservices/service/loginServiceWS.wsdl > Line Number 1, Column 671:<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:bsf="http:// > The wsdl served to the browser contains duplicates of the custom namespace prefixes defined in the original wsdl file packaged in a war inside an ear. > While debugging I only saw classes from jboss versions of xerces and xalan parsing the wsdl and serving the result to the client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6389) Integrate prunsrv.exe for OOTB Windows service

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6389?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6389: --------------------------------------- Nicklas, my scheduling this for 7.3 was meant to indicate that it's fine for that release, if you're up for that. It's too late for 7.2. > Integrate prunsrv.exe for OOTB Windows service > ---------------------------------------------- > > Key: AS7-6389 > URL: https://issues.jboss.org/browse/AS7-6389 > Project: Application Server 7 > Issue Type: Enhancement > Components: Scripts > Affects Versions: 7.2.0.Alpha1 > Environment: Windows > Reporter: Nicklas Karlsson > Assignee: Nicklas Karlsson > Fix For: 7.3.0.Alpha1 > > > It would be nice to provide pre-configured scripts for running JBoss as a service on Windows. Tomaž Cerar hinted that the prunsrv.exe in use for EAP should also be used for the community version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6389) Integrate prunsrv.exe for OOTB Windows service

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6389?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-6389: ---------------------------------- Fix Version/s: 7.3.0.Alpha1 > Integrate prunsrv.exe for OOTB Windows service > ---------------------------------------------- > > Key: AS7-6389 > URL: https://issues.jboss.org/browse/AS7-6389 > Project: Application Server 7 > Issue Type: Enhancement > Components: Scripts > Affects Versions: 7.2.0.Alpha1 > Environment: Windows > Reporter: Nicklas Karlsson > Assignee: Nicklas Karlsson > Fix For: 7.3.0.Alpha1 > > > It would be nice to provide pre-configured scripts for running JBoss as a service on Windows. Tomaž Cerar hinted that the prunsrv.exe in use for EAP should also be used for the community version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on AS7-6408: ---------------------------------- Yeah fix also addresses that. news is that you now have both :add-protocol and :add-transport operations that replace that lists that had in :add() operation but in any case I would modify your script to something like that: {noformat} # Configuring jGroups batch /extension=org.jboss.as.clustering.jgroups:add run-batch batch /subsystem=jgroups:add(default-stack=udp) # protocols is a list of string now. I have to configure socket-bindings later /subsystem=jgroups/stack=udp:add() /subsystem=jgroups/stack=udp:add-transport("type"=>"UDP","socket-binding"=>"jgroups-udp") /subsystem=jgroups/stack=udp:add-protocol("type"=>"FD_SOCK","socket-binding"=>"jgroups-udp-fd") ... (other protocols)... /subsystem=jgroups/stack=tcp:add() /subsystem=jgroups/stack=udp:add-transport("type"=>"TCP","socket-binding"=>"jgroups-tcp") /subsystem=jgroups/stack=udp:add-protocol("type"=>"MPING","socket-binding"=>"jgroups-mping") /subsystem=jgroups/stack=udp:add-protocol("type"=>"pbcast.NAKACK2") ... (other protocols)... run-batch {noformat} > Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT > --------------------------------------------------------------------------- > > Key: AS7-6408 > URL: https://issues.jboss.org/browse/AS7-6408 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.2.0.Alpha1 > Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013) > Reporter: Bernd Koecke > Assignee: Tomaz Cerar > Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml > > > When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment. > When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-22) Drools index files are getting created out of control and consume all of the hard drive space

by Jyothi Alapati (JIRA)

[ https://issues.jboss.org/browse/DROOLS-22?page=com.atlassian.jira.plugin.... ] Jyothi Alapati updated DROOLS-22: --------------------------------- Issue Type: Bug (was: Feature Request) > Drools index files are getting created out of control and consume all of the hard drive space > --------------------------------------------------------------------------------------------- > > Key: DROOLS-22 > URL: https://issues.jboss.org/browse/DROOLS-22 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Jyothi Alapati > Assignee: Mark Proctor > Attachments: repository.xml, workspace.xml > > > Drools index files are getting created out of control and consume all of the hard drive space. It used to consume 20MB for index files, but in this case, it consumed 5GB of hard disk space and stopped working. > Note: Deleting the old index files except the latest solved this problem, but we want this to be prevented, instead of deleting the index files manually. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6388) @Resource injection of Datasource on clustered SFSB fails with serialization error

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/AS7-6388?page=com.atlassian.jira.plugin.s... ] Paul Ferraro updated AS7-6388: ------------------------------ Git Pull Request: (was: https://github.com/jbossas/jboss-as/pull/3933) > @Resource injection of Datasource on clustered SFSB fails with serialization error > ---------------------------------------------------------------------------------- > > Key: AS7-6388 > URL: https://issues.jboss.org/browse/AS7-6388 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.1.3.Final (EAP) > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 7.2.0.Alpha1 > > > See JBPAPP6-1762 for details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6365) Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6365?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-6365: ----------------------------------- If this is still a bug in the latest AS7 sources and latest Hibernate, a https://hibernate.onjira.com/browse/HHH jira should be created for the defect. [Download the latest AS7 nightly build|http://community.jboss.org/thread/167590] and recreate with that. If you can recreate, then update the Hibernate jars (see [note here for some guidance|https://docs.jboss.org/author/display/AS72/JPA+Reference+Guide#J...]) to use the latest Hibernate 4.1 release (currently 4.1.9). This NPE in the Hibernate-Infinispan integration code may of been fixed already. Let us know. > Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-6365 > URL: https://issues.jboss.org/browse/AS7-6365 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Reporter: Fredrik Lagerblad > Assignee: Scott Marlow > > The caches in the 'infinispan' subsystem configured with <transaction mode="NONE"/> get stuck in state= CLEARING when you perform a programmatic evict() on them to clear the caches. (Using e.g. em.getEntityManagerFactory().getCache().evictAll() ) > > The problem seem to lie within the class 'org.hibernate.cache.infinispan.impl.BaseRegion, where the 'checkValid' method fails to clear the cache (and set back the state to VALID). The reason it fails is due to that it calls: cacheAdapter.withinTx() , which in turn tries to get the TransactionManager from the cache (which seems to be null for these non-transactional caches), and then NPEs on the tm.begin(); The NPE is caught and logs out "Could not invalidate region: null", and never set the state in VALID. So from thereon the caches are in an Invalid state and is not used anymore by Infinispan, thus leading to much performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1574: --------------------------- Fix Version/s: 3.2.7 3.3 Awaiting your pull requests for master and the 3.2 branch > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 3.2.7, 3.3 > > > Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). > New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6408) Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT

by Bernd Koecke (JIRA)

[ https://issues.jboss.org/browse/AS7-6408?page=com.atlassian.jira.plugin.s... ] Bernd Koecke commented on AS7-6408: ----------------------------------- Hello Tomaz, thanks a lot for fixing this so fast :). I tried the :add-protocol operation and it works like a charm. But it works only when I'm using a batch run. When I send /subsystem=jgroups/stack=udp:add(transport={"type"=>"UDP","socket-binding"=>"jgroups-udp"}) outside a batch, I get an error that the protocol list is missing. In earlier versions I was able to define the protocol list like the transport attribute, it wasn't a list of string. But it works well when I use :add-protocol lines after adding the stack and putting a batch - run-batch around it. I checked this with my current version, which doesn't include your fix. I will check the old way, when I get your fix from git. Thanks again, Bernd > Can't configure JGroups subsystem with CLI script in 7.2.0.Alpha1-SNAPSHOT > --------------------------------------------------------------------------- > > Key: AS7-6408 > URL: https://issues.jboss.org/browse/AS7-6408 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Affects Versions: 7.2.0.Alpha1 > Environment: Git checkout of JBossAS 7.2.0.ALPHA1 from today (28/Jan/2013) > Reporter: Bernd Koecke > Assignee: Tomaz Cerar > Attachments: standalone-ha-jgroups.cli, standalone-jgroups-fragment.xml > > > When I try to configure extension and subsystem JGroups with a CLI script, the attribute "protocols" of the stack=tcp- or stack=udp-node contains the list of configured protocols twice. The result is that the list of protocols is doubled in the standalone.xml. But having a protocol twice in one stack results in an error at next server startup. I will attach the CLI script and the resulting XML fragment. > When I shutdown the server, remove the doubled second part of each protocol list, the server comes up and all is working fine. But I can't configure it only with a CLI script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1548) UNICAST2: send STABLE message after 'last received' message

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1548?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1548: -------------------------------- You can always use the DONT_BUNDLE flag; as a matter of fact, [1] will actually bundle OOB messages by default. Bundling has nothing to do with the last-message-lost issue; an unbundled OOB message can also be lost as the last message, leading to the same issue. [1] https://issues.jboss.org/browse/JGRP-1564 > UNICAST2: send STABLE message after 'last received' message > ----------------------------------------------------------- > > Key: JGRP-1548 > URL: https://issues.jboss.org/browse/JGRP-1548 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > Contrary to UNICAST, which acks every message, UNICAST2 never acks messages, but only asks the sender to retransmit a message when a gap has been detected. > However, the drawback of this (negative ack) mechanism is the so called last-message-dropped problem: when A sends messages [1..5] to B, but 5 is dropped by the transport, as A doesn't retransmit messages until it gets a retransmission request from B, B only gets messages [1..4]. > B will *not* ask A to retransmit message 5, as B doesn't know A *sent* message 5 in the first place. > If A doesn't send message 6 for B to detect 5 is missing and asking A for retransmission, B won't get that message. > The way this is currently handled is with stable messages. A STABLE message is sent from B to A every stable_interval ms or whenever M bytes from A have been received. In the worst case, B will have to wait stable_interval ms until it finally receives message 5 from A. > SOLUTION: > In addition to time and size based STABLE messages, we could send a STABLE message whenever the batch of messages removed from the receive window has completed and the receive window is empty. > This would send a STABLE message immediately when a single message has been received (and no other messages from A are in the receive window), but it would send another STABLE message only when all (e.g.) 200 messages from A have been processed and the receive window is empty. > With this new mechanism, we could even remove the time-based STABLE messages ! > Example: > - At time T0, messages M1 and M2 are received. A STABLE message for M2 is sent. > - At T+500 (ms), messages M3-M100 are received. A STABLE message for M100 is sent > - At T+1500, M101 is received. A STABLE message for M101 is sent. > - At T+2000, M102 is received. A STABLE message for M102 is sent. > - At T+2010, M103-M500 are received. A STABLE message for M500 is sent > (Note that the example above didn't take size-based STABLE messages into account) > This is similar to the ACK based scheme in UNICAST where we only send an ack for the last message in a batch (or for a single message if not batch has been received). > This new mechanism needs to be configurable: if enabled, the time-based STABLE mechanism would be disabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 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 January 2013