[jboss-user] [Beginners Corner] - Re: Transaction not active Error sticks to the Thread causin
Call UserTransaction.commit or .rollback, which you should be doing in a finally block anyhow. Unless it's CMT, in which case this is a container bug. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4234517#4234517 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4234517 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB/JBoss] - Re: Help with Transaction Timeouts on Container Manager Tran
1) yes 2) It's the default setting for connections outside a managed tx, per the JDBC spec 3) no 4) You can't, the AS connection management code needs to be fixed fixed so it invalidates the connection. https://jira.jboss.org/jira/browse/JBAS-5080 5) You're crazy, but you can use a CheckedAction if you really want to http://www.jboss.org/index.html?module=bbop=viewtopict=142195postdays=0postorder=ascstart=10 View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4227833#4227833 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4227833 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossWS] - mysterious vanishing Service21
In JBossAS branch5x the class javax.xml.ws.Service21 seems to have vanished from jbossws-native-jaxws-ext.jar Was this intentional? It's broken things that work fine on AS 5.0.GA. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4206588#4206588 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4206588 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Performance Tuning] - reasonable defaults for CORBA configuration?
I'm having issues when running org.jboss.test.jca.test.TxConnectionManagerStressTestCase with the CORBA based transaction service (JBossTS JTS). I can make the test pass, but to do so I need to mess with various combinations of: ulimit -s ulimit -u java -Xss jacorb.poa.queue_max jacorb.poa.thread_pool_max and even then I still need to turn down the log4j threshold or the disk writes slow things down to the point that the test times out. We already recommend JTS users increase jacorb.poa.thread_pool_max (from 8 to 32), but that alone is not sufficient to get the test to pass. So, my question is: is it ok for the test to fail with the default settings for the above parameters. If not, what default parameters can we reasonably ship JBossAS with given typical user hardware specs, and/or how far can we reasonably cut back the test before it becomes meaningless. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4203284#4203284 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4203284 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Performance Tuning] - Re: reasonable defaults for CORBA configuration?
Also setting jacorb.poa.queue_wait=on may reduce the number of Threads we need in the pool to keep up with the test, which in turn may reduce the need to mess with -Xss and ulimit in order to avoid the 'java.lang.OutOfMemoryError: unable to create new native thread' problem. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4203293#4203293 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4203293 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Tomcat, HTTPD, Servlets JSP] - Re: JBoss Transactions in AS5.0.0.GA
http://www.jboss.com/index.html?module=bbop=viewtopict=119313 Use transactionManager.commit|rollback, not transaction.commit|rollback, that will probably sidestep the issue. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4197586#4197586 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4197586 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - advice on cache (mis)use for transaction log store
Hello JBossCache gurus
I've been toying with the idea of using in-memory replication across a cluster
to preserve transaction log information for JBossTS, as an alternative to
writing it to disk. What follows is my current thinking on the matter, which
you can poke holes in at your leisure.
'Memory is the new disk', so let's use it as such...
Transaction log entries are typically short lived (just the interval between
the prepare and commit phases if all goes well) but must survive a node
failure. Or, depending on the degree of user paranoia, perhaps multiple node
failures. The size is not much - a few hundred bytes per transaction. Writing
the tx log to RAID is a major bottleneck for transaction systems and hence app
servers.
JBossTS already has a pluggable interface for transaction log ('ObjectStore')
implementations, so writing one based on JBossCache is not too difficult. The
relative performance of this approach compared to the existing file system or
database stores remains to be seen. Of course it largely depends on the disk
and network hardware and utilization. I should be able to get some preliminary
numbers without too much work, but first I need to decide what configurations
to test...
Clearly the number of replicas is critical - it must be high enough to ensure
at least one node will survive any outage, but low enough to perform well.
Writes must be synchronous for obvious reasons, but ideally a node that is up
should not halt just because another member of the cluster is down. That model
would preserve information but reduce availability, which is undesirable.
So my first question is: does the cache support a mode somewhere between async
and sync, say 'return when at least M of N nodes have acked' ? I can get
something similar with buddy replication, but it's not quite the model I want -
if more than M nodes are available they should be used. Similarly the crash of
one buddy should not halt the system if there is an additional node available
such that the total live number remains more than M. Perhaps I can do this
only with the raw JGroups API, not the cache?
Also, are there any numbers on the performance as a function of groups size,
particularly mixing nodes on the same or different network segments. I'm
thinking that to get independent failure characteristics for the nodes will
probably require a distributed cluster, such that the nodes are on different
power supplies etc. Having all the nodes in the same rack probably provides a
false sense of security...
On a similar note, whilst cache puts must be synchronous, my design can
tolerate asynchronous removes. Is such a hybrid configuration possible?
Transaction log entries fall into two groups: the ones for transactions that
complete cleanly and the ones for transaction that go wrong. The former set is
much larger and its members have a lifetime of at most a few seconds. The
failure set is much smaller (hopefully empty!) but entries may persist
indefinitely.
I'm thinking of setting up the cache loaders such that the eviction time is
longer than the expected lifetime of members of the first group. What I want
to achieve is this:
Synchronous write of an entry to at least N in-memory replicas.
If the transaction works, remove, possibly asynchronously, of that information
from the cluster.
If the transaction fails, writing of the entry to disk for longer term storage.
Critically this is not the same as having all writes go through to disk. Is it
possible to configure the cache loaders to write only on eviction?
Or I guess there is another possibility: since the loader's writes are
asynchronous with respect to cache puts, is it possible to have it try to write
everything, but intelligently remove queued writes from its work list if the
corresponding node is removed before the write for its 'put' is made? That
would effectively cause the disk to operate at its max throughput without
(subject to the size limit of the work q) throttling the in-memory replication.
It thus provides an extra layer of assurance compared to in-memory only copies
but without the performance hit of synchronous disk writes.
Also, it vital to ensure there is no circular dependency between the cache and
the transaction manager. I'm assuming this can be achieved simply by ensuring
there is no transaction context on the thread at the time the cache API is
called. Or does it use transactions JTA anywhere internally?
One final question: Am I totally mad, or only mildly demented?
Thanks
Jonathan.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4185748#4185748
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4185748
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Beginners Corner] - Re: Transactions in JBoss
This approach works .. but only as long as your application can tolerate invocations of the web service without the corresponding database updates. The server may crash after invoking the web service but before committing the database updates. Or the commit on the database may fail. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4175255#4175255 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4175255 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging] - Re: Weird transaction error
https://jira.jboss.org/jira/browse/JBAS-5801 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4170036#4170036 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4170036 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossWS] - Re: NPE deploying web services in service archive in CR1 rel
This is critical for the next JBossTS release. I'd really like to see it fixed in 3.0.3, not 3.0.4. Please consider rescheduling http://jira.jboss.com/jira/browse/JBWS-2246 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4164186#4164186 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4164186 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Problem with transaction (jbossts) configuration in Tomc
BTW, do you expect the database connections used by your app to participate in the managed transaction? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4163622#4163622 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4163622 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: Could not find new XAResource to use for recovering non-
But no extra module should be needed. Actually that depends exactly what version of the server you are running and what the transaction encompasses. JBM has its own recovery module, but it's not enabled by default. The JCA used for database connections also has one, but it's only bundled in recent versions of the EAP and even then it's not turned on by default. In short, you probably don't need to write one, but you do need to hunt down one or two existing ones and wire them up. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4162553#4162553 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4162553 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Problem using Non-JTA Transaction Manager
You can use JBossTS, the JTA transaction manager from JBoss App Server, with Tomcat. It's not (yet) officially supported and generally we'd recommend you just use JBossAS and throw away the bits you don't need instead. But if you are stuck with tomcat, check out http://anonsvn.jboss.org/repos/labs/labs/jbosstm/workspace/jhalliday/tomcat-integration/ View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4155615#4155615 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4155615 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration DEPLOYMENT] - Re: http://localhost:8080 ok but http://ip address:8080 no
http://wiki.jboss.org/wiki/JBoss42FAQ View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4148335#4148335 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4148335 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Advanced Documentation] - Re: 4yr old Oracle Datasource Examples misleading with lates
It already exists: http://jira.jboss.com/jira/browse/JBAS-5235 The issue came up a JBossWorld but is on the back burner until we get on top of the transaction system feature work needed for AS 5.0 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4139257#4139257 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4139257 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Re: XADataSource vs. WrapperDataSource
Any thread in particular, or do I need to set aside a week or two to wade through the whole thing? You are right that what I did is a hack. The real solution in my view requires changes to the transactions integration spi. We can't do that in a CP release - any short term solution for EAP 4.x needs to work with the existing interfaces. Ultimately I want the AS to callback to the transaction manager when data sources for which it wants recovery enabled are deployed or undeployed. That means a new interface in the transaction spi, changes (to the data source deployers? maybe the JMS and cache too, basically anything that's using non-serializable XAResources) to lookup an implementation of that interface and invoke it, plus an implementation of the interface provided by the transaction manager. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4132810#4132810 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4132810 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Re: XADataSource vs. WrapperDataSource
Ahh, cool, thanks. That's not quite what I need, but it's close enough to give be a good idea on how to proceed. Ideally I'd like to be able to call XAManagedConnectionFactory.getXADataSource but since it's not possible I'll settle for getXADataSourceClass plus getXADataSourceProperties which between them should give me all the info I need to create the datasource myself. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4119594#4119594 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4119594 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - XADataSource vs. WrapperDataSource
Adrian or whoever is the resident JCA guru in this post-Weston era: Is there a way to get from the AS (4.2), a real XADataSource rather than the WrapperDataSource that is in JNDI? To do transaction recovery I need methods that are only on the XADataSource. Right now I'm facing the prospect of parsing the -ds.xml file myself to create the XADatasource or duplicating the same information in some other place. This seems ugly since the AS must process the file already. Is there some way to get the processed data from it rather than going back to the xml file again? Does AS 5.0 change the answer with all its fancy new meta data handling? Thanks Jonathan. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4119092#4119092 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4119092 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
Hmm, those bean entries don't get seen if they are in jboss-service.xml and putting them in the bootstrap means adding lots of new stuff to the classpath there. That leaves the option of putting them in deploy, which probably means moving things that depend on the TransactionManager too i.e. the invokers. That goes rather beyond the scope I was originally envisaging, but it may be worth considering. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4116682#4116682 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116682 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
You are missing the point and some code/xml Yes, thanks Ales, the missing link seems to be the functionality in TestServiceControllerLifecycleCallback. I had assumed that declaring the annotation was sufficient, but it seems that nothing in the current AS trunk actually does anything with that annotation, or at least not at a sufficiently early stage in the lifecycle to be useful. The code in TestServiceControllerLifecycleCallback is generic, not specific to the TransactionManager service. IMO it should be present in the AS, but I don't see it. Do I need to include it in the TS side of the integration module? To my mind the functionality should really be provided via bootstrap-beans, so in the xml for the TransactionManager I can simply reference the ServiceLifecycle bean rather than having to declare it first. Or perhaps one of the existing beans already has this functionality? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4116405#4116405 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116405 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
Yes, I follow (but don't necessarily agree with) the argument that the TransactionManager should be in deploy, but given that we can't put it there in the short term we need an alternative solution. Can the ServiceControllerLifecycleCallback stuff be moved such that it is available for use in the jboss-service.xml? To my mind it belongs not in the AOP deployer but in the bootstrap or early in the jboss-service.xml, so that services can make use of it. Otherwise as far as I can tell the TransactionManager is going to have to have its own duplicate of the same functionality, which seems less than elegant. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4116511#4116511 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116511 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
Hmm yes, that would work. All i'm trying to avoid is duplicating the java code. Duplicating a bit of xml bothers me a lot less. From the sounds of things it would be feasible to declare a bean with class=org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback in the jboss-service.xml file and inject the legacy JMX kernel into it, then reference that in the TransactionManager bean xml? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4116530#4116530 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116530 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
The JMX annotation seems a good approach at first, but when I replace the old
mbean
| mbean code=com.arjuna.ats.jbossatx.jta.TransactionManagerService
| name=jboss:service=TransactionManager
| attribute name=TransactionTimeout300/attribute
| attribute
name=ObjectStoreDir${jboss.server.data.dir}/tx-object-store/attribute
| /mbean
|
with the new annotated bean
| bean name=TransactionManager
class=com.arjuna.ats.jbossatx.jta.TransactionManagerService
|
annotation@org.jboss.aop.microcontainer.aspects.jmx.JMX(name=jboss:service=TransactionManager,
exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class,
registerDirectly=true)/annotation
|
| property name=TransactionTimeout300/property
| property
name=ObjectStoreDir${jboss.server.data.dir}/tx-object-store/property
| /bean
|
then the dependent mbeans e.g.
|mbean code=org.jboss.invocation.unified.server.UnifiedInvoker
| name=jboss:service=invoker,type=unified
| dependsjboss:service=TransactionManager/depends
| dependsjboss.remoting:service=Connector,transport=socket/depends
|/mbean
fail to find the service they depend on:
| ...
| 14:01:46,883 INFO [JMXKernel] Legacy JMX core initialized
| 14:01:59,184 INFO [WebService] Using RMI server codebase:
http://127.0.0.1:8083/
| 14:02:01,913 ERROR [ProfileServiceBootstrap] Failed to load profile:
Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS MISSING DEPENDENCIES: Name - Dependency{Required State:Actual
State}
|
| jboss:service=invoker,type=jrmp
| - jboss:service=TransactionManager{Start:** NOT FOUND **}
| - jboss:service=TransactionManager{Create:** NOT FOUND **}
| ...
| *** CONTEXTS IN ERROR: Name - Error
|
| jboss:service=TransactionManager - ** NOT FOUND **
|
Perhaps the annotation is being processed at a later stage of the lifecycle so
it's not yet present when the mbean dependencies go to look for it?
Anyhow, it seems there are issues with interop between the old mbean style and
the new bean style. My options at this point seem equally unpalatable: either
link the transactions code again some new AS library (lots of work with no
apparent advantage over the existing situation of linking against
ServiceMBeanSupport) or convert everything that depends on the transaction
manager from mbeans to beans also, transitively. I vote for option 3: do
nothing. ServiceMBeanSupport works ok, why bother with this new MC stuff?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4114219#4114219
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4114219
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
Why the mbean XML? Umm, because I want operations on it exposed via. JMX? Just because we use MC internally in the app server, that does not mean JMX goes away. There are still likely to be 3rd party tools wanting to use JMX to manage the server, so I need some way to wire the service up as an mbean. This seemed like the easiest route. If you can suggest another approach I'll happily change. Assuming of course I don't have to cascade the change to everything that depends on the tx manager and expects it to be an mbean. Thanks View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4109168#4109168 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4109168 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
Fair enough. So I can't do much of my setup in the service constructor, as I don't have the information yet at that time. I need to do the work in the start method instead. That's actually less effort for me, as it's how things currently work. The problem with that is: many other services depend on the transaction manager. As far as I can tell, under the old pre-MC semantics, depends meant 'ensure the other service has started'. As a result, work the transaction manager does in the start method would be finished before anything that depends on it was executed. Under MC, depends seems to mean 'ensure the service I depend on has reached at least the same point in the lifecycle as the one I'm transitioning to' by default. As a result, some services are being instantiated and failing because they actually depend on the transaction manager having been started, not just created. Moving the work of transaction manager setup into its service constructor would have fixed that, but it's not an option. The only alternative I see is to change the depends clause of all the things that depend on the transaction manager, such that they explicitly require it to be started. That's somewhat less elegant than I was hoping for. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4108833#4108833 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108833 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
ok, so I must be doing something wrong then. I take a class that previously extended ServiceMBeanSupport. I change it so it no longer does so. I change startService() to start(). I drop it into the app server and hey presto, thing that depend upon it break. 12:29:28,517 INFO [JMXKernel] Legacy JMX core initialized 12:29:41,350 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/ 12:29:43,385 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,type=local state=Create mode=Manual requiredState=Installed javax.naming.NameNotFoundException: TransactionManager not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:542) at org.jnp.server.NamingServer.getBinding(NamingServer.java:550) at org.jnp.server.NamingServer.getObject(NamingServer.java:556) at org.jnp.server.NamingServer.lookup(NamingServer.java:296) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.jboss.invocation.local.LocalInvoker.startService(LocalInvoker.java:77) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299) If I'm reading that trace right, the name=jboss:service=invoker,type=local bean is being started and running into problems because start() has not jet been called on the transaction manager bean. I think there is some mismatch here between the lifecycle that occured under ServiceMBeanSupport. vs. the one I get with MC. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4108862#4108862 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108862 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
I don't have a createService/create method. Besides, the invoker bean is moving into the run state, which means the transaction manger should have had start() called on it? It does not seem to get that call. I can add a create() to see if that gets called, but I'm not clear what help that would be. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4108865#4108865 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108865 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
hmm, create() does not get called either. Is it possible there is something odd with lifecycle callbacks to mbeans? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4108868#4108868 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108868 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
mbean name=jboss:service=TransactionManager
code=com.arjuna.ats.jbossatx.jta.TransactionManagerService
| property name=mbeanServerinject bean=JMXKernel
property=mbeanServer//property
| property name=transactionTimeout300/property
| property
name=ObjectStoreDir${jboss.server.data.dir}/tx-object-store/property
|/mbean
|
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4108873#4108873
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108873
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
And an example of dependency? look at jboss-service.xml in AS trunk and take your pick. |mbean code=org.jboss.invocation.local.LocalInvoker | name=jboss:service=invoker,type=local | dependsjboss:service=TransactionManager/depends |/mbean | Dunno how lifecycle works if your mbean is not an instance of Service anymore, huh? I thought the whole point of MC was that you could use POJOs. Now it appears I have to implement or subclass something? Arggg. How does that leave me any better off than not changing my code at all. I may as well stick with 'extends ServiceMBeanSupport' View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4108881#4108881 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108881 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
Thanks Ales For the MBeanServer, I've opted to try injecting. That should work, but I can't figure out the correct xml. mbean name=jboss:service=TransactionManager | code=com.arjuna.ats.jbossatx.jta.TransactionManagerService | constructor | parameter type=javax.management.MBeanServer |inject bean=JMXKernel property=mbeanServer//parameter does not work, the parameter elements are not seen. Scott suggested arg type=javax.management.MBeanServerinject | bean=JMXKernel property=mbeanServer//arg instead, which does not work either (Missing 'value' attribute in constructor arg). That leaves me stuck, as I can't figure out the syntax for injecting to an attribute in the xml. For the notifications, there does not appear any way to specify what I want in xml. I'll either have to split my bean into two or link it against the event listener code. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4108335#4108335 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108335 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: migrating from ServiceMBeanSupport
Scott That value is write once i.e. I want it set through the constructor, not exposed as a setter on the bean. Are you saying that's not possible currently? Thanks View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4108364#4108364 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4108364 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - migrating from ServiceMBeanSupport
I'm migrating some existing code that used to use JBossAS ServiceMBeanSupport to the microcontainer. I'd appreciate any information on the best approach to the following two issues: The software is used standalone as well as in JBossAS. Internally we will continue to use MBeans as that's easiest for the standalone version. The JBossAS integration previously called ServiceMBeanSupport.getServer() to get an MBeanServer for use internally. What is the equivalent call in MC (or AS5.0)? We previously used NotificationListener to register such that a method on our bean is invoked when some other bean (jboss.system:type=Server) entered a specified state (running). Is there a way to wire such a thing in MC? It's not quite the same as requiring the other bean to be started before our bean. Indeed, such a solution is not viable as we must start earlier. Thanks View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4107726#4107726 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4107726 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - version 2 documentation
I'm trying to get to grips with the MC in order to rewrite the JBossTS integration code for AS 5.0... I've read through the reference docs and also seen mention of some examples and a getting started guide. I can't find either of those online though, and there is some implication that they are not current for the 2.0.0.beta release? Please could you let me know if the example and getting started guide are sufficiently up to date to be useful (or at least not misleading) and if so, what is the mvn command to generate them from the docbook source in svn? Thanks View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4095265#4095265 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4095265 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration DEPLOYMENT] - Re: Java heap size problem
# Initial Java Heap Size (in MB) #wrapper.java.initmemory=1024 # Maximum Java Heap Size (in MB) #wrapper.java.maxmemory=2048 remove the comments? :-) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4080869#4080869 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4080869 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration DEPLOYMENT] - Re: TransactionManager Error
Give me the full trace from that java.lang.NullPointerException please View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4075183#4075183 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4075183 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossWS] - jbossws 2.0 wsconsume problem
Trying to run wsconsume from 2.0.0.GA I got javax.xml.stream.FactoryConfigurationError: Provider com.ctc.wstx.stax.WstxInputFactory not found so I went and downloaded wstx-lgpl-3.1.2.jar, put in on the classpath and tried again. This time I got: $ wsconsume.sh -v -k wsctx.wsdl JBossWS-Native stack deployed parsing WSDL... Failed to parse the WSDL. Failed to invoke WsImport java.lang.IllegalStateException: WsImport invocation failed. Try the verbose switch for more information at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:190) at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:216) at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:79) The verbose switch from the command line does not seem to get passed down to the SunRI code, so I'm stuck. Any ideas? The wsdl is from http://docs.oasis-open.org/ws-caf/ws-context/v1.0/OS/wsctx.wsdl if you want to try it yourself. Thanks Jonathan. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4068162#4068162 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4068162 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration DEPLOYMENT] - Re: I can't reach Jboss console from remote ?
I wonder if anyone could give me any suggestion Here is a suggestion: try reading the docs. http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss42FAQ View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4066144#4066144 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4066144 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration DEPLOYMENT] - Re: Jboss4.2 - Mysql5
Do you really think a bit of cut-and-paste is going to get you any more attention? If you want urgent help please try doing something more useful, like providing a test case that reproduces the behavior. Or buying a support contract. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4064483#4064483 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4064483 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration DEPLOYMENT] - Re: How to switch from JTA to JTS in JBoss AS 4.2.0.GA?
I would like to switch it to JTS in order to get XA support for database activity and JMS message creation in one atomic transaction. You don't need JTS for that unless you are using more than one JBoss instance. If the database and JMS are communicated to from the same JBoss server then JTA is sufficient. No JTS is currently available for AS 4.2, as it's got a new ORB that we don't yet support. I hope to have the first JBossTS 4.4 beta out shortly to address this. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4063360#4063360 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4063360 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration Deployment] - Re: 4.0.5 to 4.2.0 upgrade and JBossTS
Dave I'm not able to reproduce that. What you should get at startup is: 10:30:07,036 INFO [TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc. 10:30:07,036 INFO [TransactionManagerService] Setting up property manager MBean and JMX layer 10:30:07,297 INFO [TransactionManagerService] Starting recovery manager 10:30:07,505 INFO [TransactionManagerService] Recovery manager started 10:30:07,505 INFO [TransactionManagerService] Binding TransactionManager JNDI Reference ... 10:30:29,926 WARN [loggerI18N] [com.arjuna.ats.internal.jta.transaction.arjunacore.lastResource.startupWarning] [com.arjuna.ats.internal.jta.transaction.arjunacore.lastResource.startupWarning] You have chosen to enable multiple last resources in the transaction manager. This is transactionally unsafe and should not be relied upon. The last message there indicates the config param is being picked up correctly. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4055937#4055937 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4055937 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration Deployment] - Re: 4.0.5 to 4.2.0 upgrade and JBossTS
Hi Dave I'm not able to reproduce that error. Please can you post the diff between your bossjta-properties.xml and the original, plus some more information on where the error occurs. I'm assuming it's at the point where your application is deployed, in which case a test application that produces the same behavior may be helpful. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4053444#4053444 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4053444 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration Deployment] - Re: 4.0.5 to 4.2.0 upgrade and JBossTS
helgaw, what specifically are the issues you are getting? It's difficult to offer advice without having a clear description of the problem and the environment in which it occurs. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4053499#4053499 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4053499 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration Deployment] - Re: 4.0.5 to 4.2.0 upgrade and JBossTS
This has the hallmarks of a classloading issue. Is the problem only with xa-datasource? i.e. does the create work ok with local-tx-datasource? If so that would point towards an issue with XA support in the driver. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4053548#4053548 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4053548 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration Deployment] - Re: 4.0.5 to 4.2.0 upgrade and JBossTS
The issues you are seeing are consistent with mixing XA and non-XA transactions on the same connection, which earlier versions of Oracle have a problem with. Please check your datasource configuration is as per. http://wiki.jboss.org/wiki/Wiki.jsp?page=IHaveProblemsWithOracleXA If it is and you still get these problems, please send me a test case and I'll take a look. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4049641#4049641 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4049641 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration Deployment] - Re: 4.0.1sp1 upgrade to 4.2.0GA with webapp using Hibernate
That looks like a classloader issue. Does your .war contain the javax.transaction classes, perhaps from hibernate's jta.jar? If so, try removing them. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4049689#4049689 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4049689 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration Deployment] - Re: 4.0.5 to 4.2.0 upgrade and JBossTS
There is a config flag for JBossTS to allow multiple last resources. However, it's really not recommended. If you need transactions at all you probably need them to work properly! What are the issues you found when converting to XA? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4048646#4048646 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4048646 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Re: Jboss 4.2.0CR1 -
Olivier, please can you post the part of the stack trace that comes before this? At the start of the trace above, the transaction is already active, but we don't know what has previously been done with it. I suspect hibernate has enlisted a LastResource into it earlier and is trying to do so again, which will cause problems in the version you are running. You could also try grabbing the .jars for the latest stable build from http://repository.jboss.com/jboss/jbossts14/4.2.3.CR4/lib/ and installing them over the top of the existing ones. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4030587#4030587 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4030587 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
