[Design of JBossXB] - Re: problem parsing sip.xml with JBossXB
by deruelle_jean
"alex.loubyansky(a)jboss.com" wrote : If that's a choice binding based on a super class then you could try:
| ]
Not it is not. it is a substitution group. I tried anyway but I got
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Requested element and is not allowed in this position in the sequence. The next element should be condition
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
| at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
| at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:199)
| at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
| at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
| at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
| at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
| at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:188)
| at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:323)
| ... 22 more
| Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Requested element and is not allowed in this position in the sequence. The next element should be condition
| at org.jboss.xb.binding.sunday.unmarshalling.SequenceBinding$1.startElement(SequenceBinding.java:226)
| at org.jboss.xb.binding.sunday.unmarshalling.ModelGroupBinding$Cursor.startElement(ModelGroupBinding.java:185)
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:397)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
| at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
| at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(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)
I committed everything to SVN in case you want take a look at it.
But I think I find some tips after some time googling around :
http://java.sun.com/javaee/5/docs/api/javax/xml/bind/annotation/XmlElemen... Example 2
and
http://fusesource.com/docs/framework/2.1/jaxws/JAXWSElementSubstitutionJa...
I hope this will help. If you have any similarity in JBoss metadata somewhere that would be helpful
Thanks in advance
Best regards
Jean
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227857#4227857
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227857
15 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Potential Netty problem with synchronously closing connectio
by timfox
We have a JBM test which quickly creates and closes connections in a loop which eventually fails with:
| New I/O server boss #1 (channelId: 28338721, /127.0.0.1:5445) 11:41:29,851 WARN [NioServerSocketPipelineSink] Failed to accept a connection.
| java.io.IOException: Too many open files
| at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
| at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:145)
| at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink$Boss.run(NioServerSocketPipelineSink.java:205)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
|
Creating a JBM JMS and closing it involves creating a Netty bootstrap, creating a channel, closing the channel and closing the bootstrap.
This is done in quick succession.
Debugging this a bit, it seems that the netty channel disconnected event can arrive at the server significantly later than when the channel is closed from the client side.
So.. over time we end up with the rate of creating channels exceeds the rate that channel disconnected arrives at the server and the server soon runs out of file handles.
I would have thought disconnection would be synchronous, otherwise a client could easily create a DoS attack.
Any ideas?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227770#4227770
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227770
15 years, 8 months