January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2506) Maven: clean up dependencies and use new official JBoss repository (nexus)

by Geoffrey De Smet (JIRA)

Maven: clean up dependencies and use new official JBoss repository (nexus) -------------------------------------------------------------------------- Key: JBRULES-2506 URL: https://jira.jboss.org/jira/browse/JBRULES-2506 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.0.M1 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: FUTURE * Follow the instructions set up by the JBoss guys ** http://community.jboss.org/wiki/MavenRepositoryConfiguration ** For motivation, read http://java.dzone.com/articles/dont-publish-jboss-switches * Help the drools team to deal with the requirement of having a settings.xml * remove the foxtrot and forms jars from subversion ** drools/drools-examples/drools-examples-drl/lib/foxtrot-2.0.jar shouldn't be in subversion (forms neither) *** http://mvnrepository.com/artifact/foxtrot/foxtrot/2.0 *** http://mvnrepository.com/artifact/foxtrot/foxtrot-core/3.0 * make a list of all the "legacy" artifacts, see if we still need them or can upgrade to a newer version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
4
0 / 0

[JBoss JIRA] Created: (JBJPA-33) JPA Switchboard ResourceProvider support is needed

by Scott Marlow (JIRA)

JPA Switchboard ResourceProvider support is needed -------------------------------------------------- Key: JBJPA-33 URL: https://jira.jboss.org/browse/JBJPA-33 Project: JBoss JPA Issue Type: Task Reporter: Scott Marlow Assignee: Scott Marlow -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8808) Upgrade to Weld 1.1.0.Final

by Pete Muir (JIRA)

Upgrade to Weld 1.1.0.Final --------------------------- Key: JBAS-8808 URL: https://issues.jboss.org/browse/JBAS-8808 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Pete Muir Assignee: Pete Muir -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-8807) Track Component Upgrades for 6.0.1 Release

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBAS-8807?page=com.atlassian.jira.plugin.... ] Shelly McGowan updated JBAS-8807: --------------------------------- Fix Version/s: 6.0.1 > Track Component Upgrades for 6.0.1 Release > ------------------------------------------ > > Key: JBAS-8807 > URL: https://issues.jboss.org/browse/JBAS-8807 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Integration > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: 6.0.1 > > > Container task for component upgrades intended for 6.0.1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-8733) Extended persistence context not available in @PostConstruct method of stateful EJB

by Nicklas Karlsson (JIRA)

Extended persistence context not available in @PostConstruct method of stateful EJB ----------------------------------------------------------------------------------- Key: JBAS-8733 URL: https://issues.jboss.org/browse/JBAS-8733 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: 6.0.0.CR1 Reporter: Nicklas Karlsson Assignee: Carlo de Wolf Trying to use an extended @PersistenceContext injected em from a @PostConstruct method in a session bean results in a NPE -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
9
0 / 0

[JBoss JIRA] Created: (JBAS-8669) StringIndexOutOfBoundsException when deploying applications with 3 characters or less

by Rico Neubauer (JIRA)

StringIndexOutOfBoundsException when deploying applications with 3 characters or less ------------------------------------------------------------------------------------- Key: JBAS-8669 URL: https://jira.jboss.org/browse/JBAS-8669 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers Affects Versions: 6.0.0.CR1 Reporter: Rico Neubauer Assignee: Ales Justin Deploy an archive (in my case programmatically using MainDeployer, but should not matter), whose name has 3 characters or less. org.jboss.as.naming.javaee.NamingJavaEEApplicationInformer tries to truncate the last 4 characters, which results in java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at org.jboss.as.naming.javaee.NamingJavaEEApplicationInformer.getApplicationName(NamingJavaEEApplicationInformer.java:30) at org.jboss.reloaded.naming.deployers.AppNamingDeployer.internalDeploy(AppNamingDeployer.java:63) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

4
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2233) The EJB 3.1 global JNDI names are not available on remote clients

by Luis Fernando Planella Gonzalez (JIRA)

The EJB 3.1 global JNDI names are not available on remote clients ----------------------------------------------------------------- Key: EJBTHREE-2233 URL: https://issues.jboss.org/browse/EJBTHREE-2233 Project: EJB 3.0 Issue Type: Bug Components: ejb3, jndi Environment: Ubuntu Linux 10.04 64 bits Reporter: Luis Fernando Planella Gonzalez Priority: Critical The java:global namespace is not visible in remote EJB clients. This is critical, because the EJB 3.1 spec requires this. This was previously noted by Jaikiran Pai on the mailing list http://lists.jboss.org/pipermail/jboss-development/2010-November/016685.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1265) Member can not join cluster after heavy load

by Victor N (JIRA)

Member can not join cluster after heavy 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 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 is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
13
0 / 0

[JBoss JIRA] Updated: (JGRP-1272) FC: all threads are blocked at credits_available.await

by Victor N (JIRA)

[ https://issues.jboss.org/browse/JGRP-1272?page=com.atlassian.jira.plugin.... ] Victor N updated JGRP-1272: --------------------------- Attachment: jgroups-tcp.xml my config > FC: all threads are blocked at credits_available.await > ------------------------------------------------------ > > Key: JGRP-1272 > URL: https://issues.jboss.org/browse/JGRP-1272 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.11 > Environment: ubuntu 10.04.1 > Reporter: Victor N > Assignee: Bela Ban > Attachments: jgroups-tcp.xml > > > After several days of working one node can not rejoin because of FC protocol issue. The situation is reproduced once or several times per week. > The problematic node is called "gate9", its view is outdated: > [gate10.mydomain|1175] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate9.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain] > Actual view (seen by all other nodes) is: [gate10.mydomain|1176] [gate10.mydomain, gate7.mydomain, gate8.mydomain, gate11.mydomain, gate14.mydomain, gate5.mydomain, gate12.mydomain, gate2.mydomain, gate4.mydomain, gate3.mydomain, gate6.mydomain] > In log file at gate9 I can see that it sends CREDIT_REQUEST constantly: > 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=4308, conn_id=14, TCP: [channel_name=GateCluster] > 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes) > 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #2014) > 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate10.mydomain, src=gate9.mydomain, headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2014, conn_id=14, TCP: [channel_name=GateCluster] > 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.BasicTCP.sendUnicast(): dest=192.168.1.10:40001 (94 bytes) > 17/01/2011 09:55:52 UTC| TRACE | org.jgroups.protocols.UNICAST.retransmit(): gate9.mydomain --> XMIT(gate10.mydomain: #1124) > ... > At gate10 (the coordinator) I see that it receives the requests and responds: > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=2397, conn_id=14, TCP: [channel_name=GateCluster] > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #2397, conn_id=14) > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain) > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster] > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.passMessageUp(): received [dst: gate10.mydomain, src: gate9.mydomain (3 headers), size=9 bytes], headers are FC: CREDIT_REQUEST, UNICAST: DATA, seqno=1202, conn_id=14, TCP: [channel_name=GateCluster] > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.handleDataReceived(): gate10.mydomain <-- DATA(gate9.mydomain: #1202, conn_id=14) > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.UNICAST.sendRequestForFirstSeqno(): gate10.mydomain --> SEND_FIRST_SEQNO(gate9.mydomain) > 17/01/2011 09:55:55 UTC| TRACE | org.jgroups.protocols.TP.down(): sending msg to gate9.mydomain, src=gate10.mydomain, headers are UNICAST: SEND_FIRST_SEQNO, seqno=0, TCP: [channel_name=GateCluster] > ... > but I do not see any answer to this at gate9. > My config and stack traces are attached below. I do not know how to reproduce the problem in tests. But it occurs, so I can provide you with any details, just let me know. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-191) JAXPDeployer should set the setXIncludeAware on the DocumentBuilderFactory

by Anil Saldhana (JIRA)

JAXPDeployer should set the setXIncludeAware on the DocumentBuilderFactory -------------------------------------------------------------------------- Key: JBDEPLOY-191 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-191 Project: JBoss Deployers Issue Type: Feature Request Components: deployer Reporter: Anil Saldhana Set state of XInclude processing. If XInclude markup is found in the document instance, should it be processed as specified in XML Inclusions (XInclude) Version 1.0. (http://www.w3.org/TR/xinclude/) XInclude processing defaults to false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
2
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 2011