October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1079) JBM should call BytesMessage.reset() before redelivery, or not redeliver the same message instance

by Julian Scheid (JIRA)

JBM should call BytesMessage.reset() before redelivery, or not redeliver the same message instance -------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1079 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1079 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0 CR3 Environment: $ java -version java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) The unit tests have been run using the postgresql provider with Reporter: Julian Scheid Assigned To: Tim Fox Priority: Minor Consider the following sequence of events: - a durable subscriber subscribes to a topic with client acknowledgment - a BytesMessage is sent to that topic - the durable subscriber receives the message and reads its contents completely using BytesMessage.readBytes(byte[]) - the connection is closed without the subscriber acknowledging the message - the subscriber re-subscribes and re-receives the message - the subscriber re-reads the contents of the message using BytesMessage.readBytes(byte[]) In this situation, the second call to readBytes will not return any data (it will return -1 to indicate EOF and no data will be copied to the byte array passed in), unless the message is explicitly reset() by the client first. This can be verified by the unit test that I am going to attach. The JMS 1.1 specification isn't entirely clear on whether the provider is required to reset a message in this situation. However, the spec says in section 3.9, "Access to Sent Messages": "After sending a message, a client may retain and modify it without affecting the message that has been sent. The same message object may be sent multiple times. " Here, I would interpret changing the BytesMessage's internal stream pointer as a side-effect of reading its data to be a modification. Furthermore, the API docs for javax.jms.BytesMessage say "The same message object can be sent multiple times. When a message has been received, the provider has called reset so that the message body is in read-only mode for the client." (see http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/BytesMessage.html... ) This also sounds to me like a client could expect that the reset() method has been called when receiving it, regardless of whether it has been received before. Even if I am misreading the spec and it is not the provider's responsibility to reset the message in the interim, there are clients out there (e.g. StompConnect - see my corresponding ticket at http://jira.codehaus.org/browse/STOMP-5) that do expect this behavior, and so in the spirit of the Robustness Principle ("Be conservative in what you do; be liberal in what you accept from others") I would suggest to implement this behavior regardless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

3
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1101) Failure to deserialize BytesMessage contents

by Travis Brown (JIRA)

Failure to deserialize BytesMessage contents -------------------------------------------- Key: JBMESSAGING-1101 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1101 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.GA Environment: jboss-4.2.1.GA, jboss-remoting 2.2.2.SP1-brew, 7 node cluster Reporter: Travis Brown Assigned To: Tim Fox BytesMessage consumers often receive the following error: Client side: 2007-10-09 06:54:12,076 [WorkerThread#1[10.7.68.52:2209]] ERROR ServerThread - Worker thread initialization failure java.io.EOFException at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:530) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) Server side: 2007-10-09 06:54:12,071 ERROR [org.jboss.jms.wireformat.JMSWireFormat] Failed to write packet java.lang.RuntimeException: Unknown type: 76 at org.jboss.messaging.util.StreamUtils.readObject(StreamUtils.java:159) at org.jboss.messaging.core.impl.message.MessageSupport.readPayload(MessageSupport.java:435) at org.jboss.messaging.core.impl.message.MessageSupport.getPayload(MessageSupport.java:264) at org.jboss.jms.message.JBossBytesMessage.getPayloadAsByteArray(JBossBytesMessage.java:592) at org.jboss.messaging.core.impl.message.MessageSupport.write(MessageSupport.java:369) at org.jboss.jms.message.JBossMessage.write(JBossMessage.java:1048) at org.jboss.jms.wireformat.ClientDelivery.write(ClientDelivery.java:91) at org.jboss.jms.wireformat.JMSWireFormat.write(JMSWireFormat.java:237) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:983) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:559) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.remoting.Client.invokeOneway(Client.java:598) at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:815) at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:686) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.performDelivery(ServerSessionEndpoint.java:1494) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.replicateDeliveryResponseReceived(ServerSessionEndpoint.java:1094) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.handleReplicateDeliveryAck(MessagingPostOffice.java:1274) at org.jboss.messaging.core.impl.postoffice.ReplicateDeliveryAckMessage.execute(ReplicateDeliveryAckMessage.java:54) at org.jboss.messaging.core.impl.postoffice.GroupMember$DataReceiver.receive(GroupMember.java:582) at org.jgroups.JChannel.up(JChannel.java:1102) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.FRAG2.up(FRAG2.java:197) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.FC.up(FC.java:422) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:768) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:788) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:516) at org.jgroups.protocols.UNICAST.up(UNICAST.java:242) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:170) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.FD.up(FD.java:300) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.MERGE2.up(MERGE2.java:162) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.Discovery.up(Discovery.java:225) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:908) at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:850) at org.jgroups.protocols.TP.access$400(TP.java:45) at org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1296) at java.lang.Thread.run(Thread.java:595) In MessageSupport.getPayload(MessageSupport.java:264), if payload == null, it attempts to deserialize the byte array, which in this case is the content of the BytesMessage. StreamUtils.readObject(StreamUtils.java:159) will report "Unknown type" followed by the value of the first byte of the BytesMessage payload. (This could be misinterpreted during deserialization if the first byte happens to match a constant.) I am not sure how to recreate the test case yet (payload is perhaps typically non-null), but it happens frequently in our environment, where the BytesMessage is 95% of the traffic. This fix resolves the issue in our environment: diff -r org/jboss/jms/message/JBossBytesMessage.java 592c592 < return (byte[])getPayload(); --- > return (byte[])getBytesMessagePayload(); diff -r org/jboss/messaging/core/impl/message/MessageSupport.java 281a282,303 > public synchronized Object getBytesMessagePayload() > { > if (payload != null) > { > return payload; > } > else if (payloadAsByteArray != null) > { > payload = payloadAsByteArray; > payloadAsByteArray = null; > return payload; > } > else > { > return null; > } > } > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAOP-472) Wrappers lack the generic type information

by Flavia Rainone (JIRA)

Wrappers lack the generic type information ------------------------------------------ Key: JBAOP-472 URL: http://jira.jboss.com/jira/browse/JBAOP-472 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.beta1 Reporter: Flavia Rainone Fix For: 2.0.0.beta2 This issue has already been fixed by Kabir with method wrappers. This task consists of fixing the issue for all other joinpoint types. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4855) jboss-web with 4.0 dtd does not deploy

by Thomas Diesler (JIRA)

jboss-web with 4.0 dtd does not deploy -------------------------------------- Key: JBAS-4855 URL: http://jira.jboss.com/jira/browse/JBAS-4855 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Alexey Loubyansky Fix For: JBossAS-5.0.0.Beta3 [tdiesler@tddell trunk]$ ant -Dtest=org.jboss.test.ws.jaxws.samples.context.WebServiceContextJSETestCase one-test Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to resolve schema nsURI= location=http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:153) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:71) at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:86) at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:223) ... 66 more Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve schema nsURI= location=http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:306) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:402) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:199) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4857) NPE in ContainerConfigurationMetaDataWrapper

by Thomas Diesler (JIRA)

NPE in ContainerConfigurationMetaDataWrapper -------------------------------------------- Key: JBAS-4857 URL: http://jira.jboss.com/jira/browse/JBAS-4857 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Scott M Stark [tdiesler@tddell trunk]$ ant -Dtest=org.jboss.test.ws.benchmark.jaxrpc.BenchmarkDocEJBTestCase one-test getContainerConfigurations returns null configurationsWrapper = new ContainerConfigurationsMetaDataWrapper(primary.getContainerConfigurations(), defaults.getContainerConfigurations()); Caused by: java.lang.NullPointerException at org.jboss.metadata.ejb.jboss.ContainerConfigurationsMetaDataWrapper.<init>(ContainerConfigurationsMetaDataWrapper.java:60) at org.jboss.metadata.ejb.jboss.JBossMetaDataWrapper.<init>(JBossMetaDataWrapper.java:57) at org.jboss.deployment.JBossEjbParsingDeployer.parse(JBossEjbParsingDeployer.java:104) at org.jboss.deployment.JBossEjbParsingDeployer.parse(JBossEjbParsingDeployer.java:44) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1747) Merge user guide and reference guide

by Chris Laprun (JIRA)

Merge user guide and reference guide ------------------------------------ Key: JBPORTAL-1747 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1747 Project: JBoss Portal Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Chris Laprun -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1091) Selector parser should literal strings for DeliveryMode in selector expressions

by Tim Fox (JIRA)

Selector parser should literal strings for DeliveryMode in selector expressions ------------------------------------------------------------------------------- Key: JBMESSAGING-1091 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1091 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.GA Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.SP1 In the current selector parser, DeliveryMode in a selector expression is expected as the integer value, but should "PERSISTENT" or "NON_PERSISTENT" string literals. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1047) ServerPeer.listMessageCountersAsHTML sorted by Name

by Aslak (JIRA)

ServerPeer.listMessageCountersAsHTML sorted by Name --------------------------------------------------- Key: JBMESSAGING-1047 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1047 Project: JBoss Messaging Issue Type: Patch Reporter: Aslak Assigned To: Tim Fox Added name sort to the MessageCounter list. Gives a better overview when having lots of Queue/Topic/Subscriptions on the server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
7
0 / 0

[JBoss JIRA] Updated: (GPD-3) implement a generation mechanism for the new task forms

by Koen Aers (JIRA)

[ http://jira.jboss.com/jira/browse/GPD-3?page=all ] Koen Aers updated GPD-3: ------------------------ Fix Version/s: jBPM jPDL Designer 3.1.3 Affects Version/s: (was: jBPM JPDL Designer 3.1.0 alpha1) > implement a generation mechanism for the new task forms > ------------------------------------------------------- > > Key: GPD-3 > URL: http://jira.jboss.com/jira/browse/GPD-3 > Project: JBoss jBPM GPD > Issue Type: Task > Components: jpdl > Reporter: Koen Aers > Assigned To: Koen Aers > Fix For: jBPM jPDL Designer 3.1.3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1111) JBM 1.4.0 in ESB from svn revision 15800 writes WARNING to server log: WARN [SecurityMetadataStore] *** THE DEFAULT SUCKER USER PASSWORD HAS NOT BE CHANGED FROM THE INSTALLATION DEFAULT

by Len DiMaggio (JIRA)

JBM 1.4.0 in ESB from svn revision 15800 writes WARNING to server log: WARN [SecurityMetadataStore] *** THE DEFAULT SUCKER USER PASSWORD HAS NOT BE CHANGED FROM THE INSTALLATION DEFAULT ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1111 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1111 Project: JBoss Messaging Issue Type: Bug Components: JMS Security Affects Versions: 1.4.0.GA Environment: RHEL5 Java 1.5 JBESB - At revision 15800 JBM 1.4.0.GA Reporter: Len DiMaggio Assigned To: Tim Fox Priority: Minor This is coming from: jboss-messaging-1.4.0.GA-src/src/main/org/jboss/jms/server/ServerPeer.java 14:49:33,472 WARN [SecurityMetadataStore] *** THE DEFAULT SUCKER USER PASSWORD HAS NOT BE CHANGED FROM THE INSTALLATION DEFAULT - THIS IS A SECURITY RISK - PLEASE CHANGE THIS!! ** I noticed this with ESB - from svn revision 15800 on oct 12 - http://jira.jboss.com/jira/browse/JBESB-1172 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007