[JBoss JIRA] Created: (JBXB-98) Add property replacement support for ObjectModelFactory parsing
by Scott M Stark (JIRA)
Add property replacement support for ObjectModelFactory parsing
---------------------------------------------------------------
Key: JBXB-98
URL: http://jira.jboss.com/jira/browse/JBXB-98
Project: JBoss XML Binding (JBossXB)
Issue Type: Feature Request
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: JBossXB-2.0.0.CR2
We only do property reference replacement when doing schema based parsing. The legacy ObjectModelFactory adapter model has not support for this. The DelegatingObjectModelFactory.setValue(Object o, UnmarshallingContext navigator, String namespaceURI, String localName, String value) needs to be updated to allow for this. It can use reflection on the associated ObjectModelFactory for an isReplacePropertyRefs() method to allow it to control whether replacement happens. In the absence of such a method replacement should be turned on by default.
--
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
19 years, 4 months
[JBoss JIRA] Created: (JBAS-4204) BasicQueue.removeAllMessages is not handling msgs with timeouts that are unacked
by Scott M Stark (JIRA)
BasicQueue.removeAllMessages is not handling msgs with timeouts that are unacked
--------------------------------------------------------------------------------
Key: JBAS-4204
URL: http://jira.jboss.com/jira/browse/JBAS-4204
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS service
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1
Reporter: Scott M Stark
Assigned To: Adrian Brock
Fix For: JBossAS-4.2.0.GA
There is an inconsistency with the way message removal is done when msgs with expirations that are unacked. The problem is that the call to dropMessage(message) for the timeout event clears the MessageReference when its removed from the cache. When the unacknowledgedMessages are then processed, the associated MessageReference has been nulled out, and the following NPE results:
java.lang.NullPointerException
at org.jboss.mq.server.MessageReference.redelivered(MessageReference.java:180)
at org.jboss.mq.server.BasicQueue.nackMessage(BasicQueue.java:382)
at org.jboss.mq.server.BasicQueue$RestoreMessageTask.run(BasicQueue.java:1115)
at org.jboss.mq.pm.TxManager.addPostCommitTask(TxManager.java:103)
at org.jboss.mq.server.BasicQueue.acknowledge(BasicQueue.java:558)
at org.jboss.mq.server.BasicQueue.removeAllMessages(BasicQueue.java:651)
at org.jboss.mq.server.JMSTopic.destroyDurableSubscription(JMSTopic.java:315)
at org.jboss.mq.sm.AbstractStateManager.setDurableSubscription(AbstractStateManager.java:119)
at org.jboss.mq.server.JMSDestinationManager.destroySubscription(JMSDestinationManager.java:620)
at org.jboss.mq.server.JMSServerInterceptorSupport.destroySubscription(JMSServerInterceptorSupport.java:261)
at org.jboss.mq.security.ServerSecurityInterceptor.destroySubscription(ServerSecurityInterceptor.java:197)
at org.jboss.mq.server.TracingInterceptor.destroySubscription(TracingInterceptor.java:661)
at org.jboss.mq.server.JMSServerInvoker.destroySubscription(JMSServerInvoker.java:261)
at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:183)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:369)
at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:377)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
at java.lang.Thread.run(Thread.java:534)
This appears to be caused by an invalid attempt to unsubscribe a durable subscription, however, the failure results in the not being able to reestablish the subscription latter:
2007-02-08 07:50:03,373 ERROR [org.jboss.mq.il.uil2.SocketManager] Failed to handle: org.jboss.mq.il.uil2.msgs.SubscribeMsg26446166[msgType: m_subscribe, msgID: 5, error: null]
java.lang.NullPointerException
at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:104)
at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:133)
at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:596)
at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:297)
at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:142)
at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:769)
at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:297)
at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:166)
at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:369)
at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:377)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
at java.lang.Thread.run(Thread.java:534)
The problem here is that the handling of the unsubscribe in AbstractStateManager.setDurableSubscription results in the durQueues being removed in JMSTopic.destroyDurableSubscription, but the AbstractStateManager.removeDurableSubscription(subscription) is not called because of the previous NPE.
Presumably the cleanup in AbstractStateManager.setDurableSubscription should be doing:
try
{
dest.destroyDurableSubscription(sub);
}
finally
{
try
{
// straight deletion, remove subscription - call subclass
removeDurableSubscription(subscription);
}
catch(Throwable t)
{
log.warn("Failed to remove subscription: "+subscription, t);
}
}
--
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
19 years, 4 months
[JBoss JIRA] Created: (JBAS-4203) datasource initialization after webapp is loaded
by Sudip Shretsha (JIRA)
datasource initialization after webapp is loaded
------------------------------------------------
Key: JBAS-4203
URL: http://jira.jboss.com/jira/browse/JBAS-4203
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.4.GA
Environment: OS: Fedora Core 4; JVM: Sun J2SE 1.5.0_10
Reporter: Sudip Shretsha
Just for clarification: my .war filename: app.war and the deployed dir name in deploy folder: myApp.war.
I have deployed my expanded webapp (app.war) in a directory myApp.war in the deploy folder. I have my datasources defined in mysql-ds.xml in the deploy folder as well. Problem is I initialize Hibernate SessionFactories in a class that extends Struts' Plugin (**I am not using .har) during the application startup. But in JBoss, this initialization seems to occur before JBoss initializes the datasources.....
Because of this deployment fails the first time. Then right after JBoss deploys the datasources, it starts to deploy my application again and everything seems to work. Even though it works, it is confusing if you are deploying multiple apps in the same server.
Strangely, this problem does not occur if I directly deploy my application as app.war in the deploy folder. In this case, JBoss seems to deploy the datasources first, then app.war sequentially... that way application deployment happens correctly the first time.
tried various suggestions on the user forum, it still does not seem to work.
--
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
19 years, 4 months
[JBoss JIRA] Created: (JGRP-372) TCP with SSL
by Bela Ban (JIRA)
TCP with SSL
------------
Key: JGRP-372
URL: http://jira.jboss.com/jira/browse/JGRP-372
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4.1
Attachments: tcp_ssl.jar
>From Hal Hildebrand:
Here's the straight TCP version, as I am still working on the handshake
implementation for the TCP_NIO_SSL protocol. This protocol stack element
provides security and authentication (using client side authentication) for
a JGroups TCP stack.
Like the NIO version, this required four minor modifications in the
ConnectionTable class. These modifications allow one to subclass to create
a connection table which uses SSL for the connections. Finally, there is a
new protocol stack element, TCP_SSL, which one can add to a stack to make
use of it.
As with my previous request, it would be nice to have the changes to
ConnectionTable make it into the mainline, as I currently have to overwrite
the original class to easily implement this. The mods are simple and
innocuous (marked with "HSH").
Right now, the TCP_SSL needs to be configured with an SSLContext. I didn't
bother with integrating with the normal JGroups mechanism using properties
from the configuration because I consider it inherently insecure to ensconce
my passwords in configuration files, but the changes to enable this are
straight forward. Currently, to configure the factory for the protocol
layer, do something like the following before connecting your channel:
// Construct your Jchannel
JChannel jchannel = ...
// Access your protocol stack
ProtocolStack protocolStack = jchannel.getProtocolStack();
// Retrieve the TCP_SSL protocol layer
TCP_SSL protocol = (TCP_SSL) protocolStack.findProtocol("TCP_SSL");
// Create your SSLContext
SSLContext sslContext = ....
// Set up the protocol
protocol.setSslContext(sslContext);
// Connect your channel
jchannel.connnect("my-group");
Cheers.
--
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
19 years, 4 months
[JBoss JIRA] Created: (JGRP-423) SEQUENCER changes
by Bela Ban (JIRA)
SEQUENCER changes
-----------------
Key: JGRP-423
URL: http://jira.jboss.com/jira/browse/JGRP-423
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Attachments: cluster-jgroups-config.xml.nopool, SEQUENCER.java, SEQUENCER.java.diff
[email from Matthieu Bentot]
Hi,
Sorry for the late answer.
Bela Ban wrote:
> Hi Matthieu,
>
> Matthieu Bentot wrote:
> > Hi all,
> >
> > First off, I wanted to thank everybody for the great job on
> > JGroups, which has been very useful to us.
> >
> > Attached are a few changes we've made (all up to date as of 2.4): -
> > TAG (new) is a very simple layer that adds a tag to messages going
> > down the stack and prints them on the way up. I found it useful for
> > debugging purposes.
>
> I'll add it if you add javadoc that explains what it does
>
> > - IDLE (new) simply broadcasts a message with a special tag if
> > nothing has been sent in a configurable interval. We had an issue
> > with NAKACK where a node would be waiting for an answer to a
> > message while the recipient was waiting for the end of a message.
> > This may have been resolved since then :-)
>
> I don't see the point of this. If you discovered a bug, we should fix
> ths bug and not add a new protocol. Maybe you ran into the "Last
> Message dropped in NAKACK" issue (JGroups/doc/design/varia2.txt)
> issue ? This is a matter of changing the timeout in STABLE.
You're right of course. It was more of an issue of nodes hanging for a few seconds every so often, really, and that was back in th 2.2 days.
I'll try without it with a newer version and to change the timouts.
> > - SEQUENCER (update) had a java synchronization issue that was
> > causing a deadlock when using a threadless stack (like we do).
>
> Can you send me a patch against CVS head ? You changed the format, so
> I couldn't really see what the changes were all about...
>
> > Finally, I added a way to bypass ordering, in the form of an empty
> > internal header (SEQUENCER.UNORDERED_HEADER). By adding this header
> > to a message, an application can tell the SEQUENCER layer that the
> > message is not subject to ordering.
>
> I'd prefer you to use Message.OOB (msg.setFlag(Message.OOB),
> msg.isFlagSet(Message.OOB)), that's the right mechanism to bypass
> ordering on a per-message basis.
>
> > This is useful to us because (part of) our application is a
> > distributed persistent transactional database; most of the traffic
> > is protected by transactions, for which we can avoid the
> > performance penalty using this mechanism (I was originally using
> > CAUSAL for that reason, even though a total ordering was the
> > correct choice).
>
> Yes, I agree this is useful, but the impl should use the OOB flag
> rather than adding a header. Can you change this and re-submit ?
Ah, yes, that's much better than the dodgy hack :-). I'm a bit unclear about whether the layer should clear the OOB flag or not before passing down. This version does.
I'm not sure a diff will help because I had to change the structure a bit to fix the synchronization issue.
The other change I made was to stop sending on a view change until the new coordinator signals that all the members are in the view. This avoids losing messages on startup when nodes join too fast, and then some messages get discarded because the nodes can't decide whether they belong to a view they were in.
I also took the opportunity to parameterize the collections. The attached diff is against cvs current.
I tried it a few times and it seems to work fine.
> > There is another change that will be coming soon (as soon as I get
> > it ported to 2.4, unless you want it against 2.3SP1 :-), but it's a
> > bit problematic. Simply put, it allows JGroups to use pools for use
> > messages and message fragments.
>
> The experts say we don't need pools anymore, especially in JDK5 where
> the VM maintains internal pools anyway. What's your motivation ?
> Performance ? Did you mesure a performance increase using pools for
> messages ?
Yes, I know. However, AFAIK, the experts say that because, with modern GCs, allocation and deallocation are faster on the heap (in the new generation), with the drawback of having a slight pause every so often which is not noticeable anyway in the case of webapps (and most desktop apps). Also pools tend to hog the tenured space even when they're not actually used.
I think the situation is bit different in this case because:
- the pool is constantly in use;
- we're allocating arrays, for which allocation from a pool is much faster, since it doesn't need to initialize them to 0s;
- GC pauses are not negligible, because (if the app is high throughput or low-latency) it can cause the other nodes to hold too. So if you pause, say, .5s every 10s, and you got 4 nodes, the cluster can be idling a fifth of the time. If have no real numbers here, and of course good multithreading can help, but you get the idea.
Anyway, I ran the JGroups perf bench to compare. 4 nodes transmitting 2GB on 4*Sun v40z, each with 4 opterons, on a dedicated Gig-E LAN (only traffic is JGroups). Sun 1.5.0_10-b03 JVM with 1GB of memory. I attached the non-pooled config.
I get the following results (that's the average of the 3 medians of 5 runs). Keep in mind that this is 2.3SP1.
size no pool pool
1k 16.2MB/s 15.4MB/s 10k 23.3MB/s 28.8MB/s 100k 26.6MB/s 41.6MB/s 1M 24.9MB/s 42.8MB/s
It's worth noting that this config is quite ideal for the GC (few long time references to move out of the new generation, parallel GC on a separate proc).
The 1k test uses no pooling (the messages are not fragmented).
The 10k one only uses the fragment pool (explaining the lower gain). If the message pool threshold is lowered to include them, it's about 32MB/s.
As I mentioned, because of the Message API, it is required to maintain 2 pools, one for fragments, one for messages. This is ungainly and inefficient. If Message didn't expose its internal array, the message pool could go away, and pooling would be more efficient for small messages. It would also save one extra copy.
Oh, yeah, cvs seems to be missing the following annotations: org.jgroups.annotations.GuardedBy and import org.jgroups.annotations.Immutable.
Regards,
Matthieu
--
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
19 years, 4 months