April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBMESSAGING-1802) Sending MapMessage with large String value is broken

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1802?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1802: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > Sending MapMessage with large String value is broken > ---------------------------------------------------- > > Key: JBMESSAGING-1802 > URL: https://issues.jboss.org/browse/JBMESSAGING-1802 > Project: JBoss Messaging > Issue Type: Feature Request > Affects Versions: 1.4.0.SP3.CP10, 1.4.6.GA > Reporter: Justin Bertram > Assignee: Yong Hao Gao > Fix For: 1.4.8.SP12 > > > Sending a javax.jms.MapMessage that has a String value >= 65536 characters fails. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1870) ClientSocketWrapper constructors have a redundant call to createStreams()

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1870?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1870: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > ClientSocketWrapper constructors have a redundant call to createStreams() > ------------------------------------------------------------------------- > > Key: JBMESSAGING-1870 > URL: https://issues.jboss.org/browse/JBMESSAGING-1870 > Project: JBoss Messaging > Issue Type: Bug > Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA > Reporter: Ron Sigal > Assignee: Yong Hao Gao > Priority: Minor > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12 > > > org.jboss.jms.client.remoting.ClientSocketWrapper is derived from org.jboss.remoting.transport.socket.ClientSocketWrapper. The constructors of the former look like > public ClientSocketWrapper(Socket socket) throws IOException > { > super(socket); > createStreams(socket, null); > } > public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception > { > super(socket, metadata, timeout); > createStreams(socket, metadata); > } > and the constructors of the latter look like > public ClientSocketWrapper(Socket socket) throws IOException > { > super(socket); > createStreams(socket, null); > } > public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception > { > super(socket, timeout); > createStreams(socket, metadata); > } > The calls to createStreams() in the JBossMessaging versions of ClientSocketWrapper is redundant. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1866) Adapt JBM tests to new failover model

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1866?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1866: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > Adapt JBM tests to new failover model > ------------------------------------- > > Key: JBMESSAGING-1866 > URL: https://issues.jboss.org/browse/JBMESSAGING-1866 > Project: JBoss Messaging > Issue Type: Task > Components: Tests and Performance > Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12 > > > In jbm test suite some tests will fail if the 'keepOldFailoverModel' is set to false. This is because with new model, the failover for a dead node doesn't happen immediately. This affects all tests which expect a failover to happen after a certain timeout. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1843) Incorporate JBREM-1144

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1843?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1843: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > Incorporate JBREM-1144 > ---------------------- > > Key: JBMESSAGING-1843 > URL: https://issues.jboss.org/browse/JBMESSAGING-1843 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Remoting > Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Priority: Critical > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12 > > -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1852) Make the connection failover retry paramters configurable

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1852?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1852: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > Make the connection failover retry paramters configurable > --------------------------------------------------------- > > Key: JBMESSAGING-1852 > URL: https://issues.jboss.org/browse/JBMESSAGING-1852 > Project: JBoss Messaging > Issue Type: Enhancement > Components: JMS Client Manager > Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12 > > > Currently if a connection is broken and the client tries to fail over to a new connection, the retry times and intervals are hardcoded. (10 and 2sec resp.) > Make it configurable can suit some use cases where the server is shutdown and come back later. (with hardcoded retry, the failover may have given up before the server is back). -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1834) JBoss Messaging XA Recovery Configuration Documentation needs update

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1834?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1834: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > JBoss Messaging XA Recovery Configuration Documentation needs update > -------------------------------------------------------------------- > > Key: JBMESSAGING-1834 > URL: https://issues.jboss.org/browse/JBMESSAGING-1834 > Project: JBoss Messaging > Issue Type: Task > Components: Documentation and Training > Affects Versions: 1.4.7.GA > Reporter: Bruno Machado > Labels: Documentation,, jboss, messaging > Fix For: 1.4.8.SP12 > > > Chapter JBoss Messaging XA Recovery Configuration[1] has the following paragraph: > >> DefaultJMSProvider ships with JBoss Enterprise Application Platform. It is defined in $JBOSS_HOME/server/$PROFILE/conf/jms-ds.xml (or, in a clustered environment, hajndi-jms-ds.xml) > It is confused because jms-ds.xml is placed on $JBOSS_HOME/server/$PROFILE/deploy/messaging, and for clustered environment there is no hajndi-jms-ds.xml. > [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5... -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1923) Node cannot enter cluster during failover

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1923?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1923: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > Node cannot enter cluster during failover > ----------------------------------------- > > Key: JBMESSAGING-1923 > URL: https://issues.jboss.org/browse/JBMESSAGING-1923 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Clustering > Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP8 > Reporter: Terrence Cowhey > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12 > > > The setup is a cluster of 4 nodes, arranged into 2 'sites': > Primary Site: site2blade1, site2blade2 > Secondary Site: site2blade3, site2blade4 > After restarting the nodes of the secondary site many times, one of them fails to come up, with a deployment failure in JMS - the PostOffice fails with an IllegalStateException. > The previous restarts were induced by either 'kill -KILL' on the app server, or a graceful shutdown. The final (failed) restart was on site2blade4, and was induced by a graceful shutdown of the app server. > The IllegalStateException is being thrown during a failover while a new node is starting to join the cluster. Waiting 60 seconds to start the node in question fixes the issue. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1905) Proper handling the timeout issue in receive(timeout)

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1905?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1905: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > Proper handling the timeout issue in receive(timeout) > ----------------------------------------------------- > > Key: JBMESSAGING-1905 > URL: https://issues.jboss.org/browse/JBMESSAGING-1905 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Facade > Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP3 > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12 > > -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMESSAGING-1880) JMSRedelivered not properly set when a client exits without closing the JMS resources (connection, session, consumer)

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/JBMESSAGING-1880?page=com.atlassian.jira.... ] Yong Hao Gao updated JBMESSAGING-1880: -------------------------------------- Fix Version/s: 1.4.8.SP12 (was: 1.4.8.SP11) > JMSRedelivered not properly set when a client exits without closing the JMS resources (connection, session, consumer) > --------------------------------------------------------------------------------------------------------------------- > > Key: JBMESSAGING-1880 > URL: https://issues.jboss.org/browse/JBMESSAGING-1880 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Facade > Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12 > > > If a client consumer receives a message and exit without acknowledging it or close the connection/session/consumer object, the message will be cancelled at the server side. When the message is delivered, its JMSRedelivered flag should be true. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3297) Hibernate with enabled enhancer throws error at deployment

by Markus D (JIRA)

[ https://issues.jboss.org/browse/WFLY-3297?page=com.atlassian.jira.plugin.... ] Markus D updated WFLY-3297: --------------------------- Description: When I enable the enhancer in the persistence.xml then I receive an error from javassist at deployment. https://community.jboss.org/message/871056#871056 public class TornadoStrikeSkill extends SelfTargetSkill { private static final long serialVersionUID = 1123460060768124078L; public TornadoStrikeSkill() { } @Override protected void executeSkill() { ..... GameObjectService gameObjectService = BeanLocator.lookup(GameObjectService.class); // getting the characters from an EJB for(GameCharacter victim : gameObjectService.calculateVictims()) { } } public class GameCharacter extends GameObject { @OneToMany(mappedBy = "caster") private List<Skill> skills = new ArrayList<Skill>(); When I remove the for loop the error is gone. When I deploy the same application on JBoss 7.1 it works. So I guess the classloading has changed. Maybe the cyclic dependency messes with the javassist? was: When I enable the enhancer in the persistence.xml then I receive an error from javassist at deployment. https://community.jboss.org/message/871056#871056 > Hibernate with enabled enhancer throws error at deployment > ---------------------------------------------------------- > > Key: WFLY-3297 > URL: https://issues.jboss.org/browse/WFLY-3297 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading > Affects Versions: 8.1.0.CR1 > Reporter: Markus D > Assignee: David Lloyd > Labels: hibernate > Attachments: verbose_log.txt > > > When I enable the enhancer in the persistence.xml then I receive an error from javassist at deployment. > https://community.jboss.org/message/871056#871056 > public class TornadoStrikeSkill extends SelfTargetSkill { > private static final long serialVersionUID = 1123460060768124078L; > public TornadoStrikeSkill() { } > @Override > protected void executeSkill() { > ..... > GameObjectService gameObjectService = BeanLocator.lookup(GameObjectService.class); > // getting the characters from an EJB > for(GameCharacter victim : gameObjectService.calculateVictims()) { > > } > } > public class GameCharacter extends GameObject { > @OneToMany(mappedBy = "caster") > private List<Skill> skills = new ArrayList<Skill>(); > When I remove the for loop the error is gone. When I deploy the same application on JBoss 7.1 it works. So I guess the classloading has changed. > Maybe the cyclic dependency messes with the javassist? -- 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

12 years, 2 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 April 2014